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PART  SYN:  OVERVIEW 


This  pe^  intentionalfy  lefi  Monk. 


OV.1.  INTRODUCTION 

^thesis  is  a  methoddogy  fior  oonstnicting  software  systems  as  instances  d  a  family  of  systems  that 
have  similar  descriptions  (Campbell,  Faulk,  and  Weiss  1990).  This  guidebook  provides  an  introduc¬ 
tion  to  the  practice  of  the  ^thesis  methodology  of  software  development  T)  the  d^ee  that  you  un¬ 
derstand  the  essential  similarities  and  variations  in  the  systems  you  build.  Synthesis  enables  you  to 
aq)loit  those  similarities  to  eliminate  redundant  work.  A  mature  organization  will  be  able  to  satisfy 
the  needs  of  its  customers  by  answering  the  questions  that  are  left  open  because  of  variations. 

^thesis  focuses  on  your  need  both  to  deliver  high  quality  products  to  customers  and  to  accomfdish 
t^  profitably,  lb  this  end,  a  Synthesis  process  consists  of  two  subprocesses:  Application  Engineering 
and  Domain  Engineering.  Application  Engineering  is  how  a  group  (or  project)  in  your  organization 
CTeates  a  product  to  meet  customer  requirements.  Domain  Engineering  is  how  your  organization  im¬ 
proves  productivity  by  creating  a  product  family  and  a  su|^rting  Application  Engineering  process, 
tailored  for  {n-pjects  in  your  business  area.  The  details  of  these  subproce^  will  differ  dependii^  on  die 
capabilities  of  your  organization  to  practice  reuse  effectively. 

Since  projects  in  the  same  business  area  tend  to  build  ^ems  that  satisfy  similar  needs,  these  systems 
can  be  thought  of  as  instances  of  a  family.  AfamL'y  of  systems  is  abasis  for  a  flodble  approach  to  stan¬ 
dardization  that  can  accommodate  diverse  and  dianging  needs.  A  business  area  whose  objectives  are 
fulfilled  by  a  family  is  a  domain.  Both  the  mission  of  an  organization  and  the  changing  needs  of  its 
customers  determine  the  objectives  of  that  business-area  organization  (i.e.,  product  line).  Synthesis 
is  a  comprehensive,  business-area-level  solution  to  problems  of  software  productivity,  pr^uct  quali¬ 
fy,  manageabilify,  and  responsiveness  in  the  building  of  systems  to  meet  diverse  and  changing  needs. 
Syuthesis  is  a  systematic  approach  to  software  development  founded  on  the  belief  that  the  resources 
of  a  business-area  organization  slrauld  be  managed  not  only  to  meet  the  immediate  needs  of 
customers,  but  also  as  an  investment  in  future  capabilify. 

This  guidebook  describes  two  instances  of  a  Synthesis  family  of  processes,  one  that  is  opportunistic 
in  character,  the  other  that  is  leveraged.  The  of^rtunistic  process  is  oriented  toward  organizations 
having  modest  reuse  needs  and  capabilities.  The  leveraged  process  is  oriented  toward  organizations 
that  can  make  a  greater  commitment  to  reuse  and  that  have  more  advanced  needs  and  capabilities. 

1.1  DOCUMENT  PURPOSE,  SCOPE,  AND  AUDIENCE 

This  guidebook  defines  ^thesis,  a  sound  ai^oach  for  effective  family-oriented  software 
development.  It  serves  as  a  detailed  guide  to  the  practice  of  Synthesis  and  helps  you  begin  to  [vactice 
it.  As  you  gain  experience  in  practicing  ^thesis,  you  will  be  able  to  refine  and  modify  this  guidance 
to  meet  the  spedfic  needs  of  your  organization  more  effectively. 

The  scope  of  this  guidebook  includes  all  activities  and  work  products  related  to  production  of  software 
and  support  of  the  needs  and  objectives  of  a  business-area  organization  and  its  customers.  Synthesis 
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OV.l.  Introduction 


activity  is  initiated,  via  a  Reuse  Adoption  process  (Software  Productivity  Consortium  1992c),  with  the 
establishment  of  organizational  business  objectives  for  a  domain.  In  addition,  various  Synthesis  activi¬ 
ties  require  you  to  standardize  management,  requirements,  design,  implementation,  and  verification 
and  validation  practices  throughout  your  organization.  Synthesis  is  an  integrating  framework  for  the 
methods  you  choose  to  standardize  your  practices.  Detailed  descriptions  of  particular  methods  are 
generally  outside  the  scope  of  this  guidebook.  Such  descriptions  are  available  to  you,  often  in  other 
Consortium  publications  that  are  referenced,  where  appropriate,  throughout  this  guidebook.  Stan¬ 
dardization  of  these  activities  in  terms  of  purpose  and  technique,  using  methods  of  your  choice,  is 
essential  to  an  effective  Synthesis  practice. 

The  audience  for  this  guidebook  includes  business-area  managers,  project  managers,  and  engineers 
of  all  disciplines  who  work  together  to  accomplish  the  objectives  of  a  business-area  organization. 
Readers  should  be  knowledgeable  and  experienced  in  the  standard  (or  prevailing)  software  develop¬ 
ment  methods  used  in  their  organization,  but  are  assumed  to  have  no  experience  with  Synthesis.  Prac¬ 
tical  use  of  this  release  of  the  guidebook  requires  the  participation  of  knowledgeable  technologists. 
Pilot  projects  are  a  requisite  first  step  in  transitioning  to  production  use. 

1.2  DOCUMENT  STATUS  AND  EVOLUTION 

Release  of  this  guidebook  ends  the  third  year  of  a  multiyear  effort  to  develop  a  guidebook  for  a  family 
of  Synthesis  software  processes  for  use  business-area  organizations.  This  guidebook  describes  the 
family,  in  overview,  and  two  representative  processes,  in  detail.  The  first  of  these  processes  is  opportu¬ 
nistic  in  character  and  assumes  a  low  degree  of  organizational  reuse  capability  and  commitment;  the 
second  process  is  oriented  to  leveraged  reuse  and  assumes  a  moderately  high  degree  of  reuse  capabili¬ 
ty  and  commitment.  Either  process  may  be  adopted  as-is  or  tailored  to  fit  the  particular  needs  and 
capabilities  of  your  organization. 

This  guidebook  is  a  revision  of  the  Synthesis  Guidebook  (Software  Productivity  Consortium  1991a)  and 
its  successor,  th&Domain  Engineering  Guidebook  (Software  Productivity  Consortium  1992a).  The  cur¬ 
rent  name  was  chosen  because  the  guidebook  covers  the  entire  software  life-cycle  process  for  a  do¬ 
main,  comprising  Application  Engineering  as  well  as  Domain  Engineering.  Major  extensions  in  this 
version  include  an  expanded  characterization  of  the  Synthesis  process  family,  better  integration  with 
work  on  the  Evolutionary  Spiral  Process  (ESP)  Model  (Software  Productivity  Consortium  1992b), 
additional  and  improved  activity  descriptions,  and  improved  examples. 

Appendix  A  desaibes  the  levels  of  maturity  through  which  the  guidebook  and  each  of  its  sections  will 
progress,  and  the  current  status  of  each.  TTie  Consortium  sponsors  pilot  projects  with  industrial  and 
government  partners  for  the  exploration  and  adoption  of  Synthesis.  Such  projects  are  the 
Consortium’s  primary  vehicle  for  improving  the  content  and  quality  of  this  guidebook. 

1.3  RELATED  PUBLICATIONS 

Publication  of  this  guidebook  follows  4  years  of  work  on  Synthesis  at  the  Consortium.  The  Consortium 
has  delivered  a  continuing  series  of  other  work  products  that  describe  various  aspects  of  Synthesis. 
Information  about  Synthesis  is  evolving  as  experience  accumulates  fi-om  pilot  projects.  Recently 
delivered  work  products  include: 

•  Systematic  Reuse:  The  Competitive  Edge  (Software  Productivity  Consortium  1991b),  a  video 
that  briefly  explains  the  concepts  and  rationale  for  Synthesis  with  an  orientation  to  the 
concerns  of  executive  management. 
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Introduction  to  Synthesis  (Campbell,  Faulk,  and  Weiss  1990),  whidi  provides  an  informal 
explanation  of  the  Synthesis  vision  and  its  foundations. 


•  Introducing  Systematic  Reuse  to  the  Command  and  Control  Systems  Division  of  Rockwell 
International  (O’Connor  and  Mansour  1992),  which  desaibes  the  experience  of  a  pilot  project, 
at  Rockwell,  which  adopted  and  is  proceeding  to  institutionalize  use  of  a  Synthesis  process  in 
their  business  organization. 

•  Domain  Engineering  Validation  Case  Study — Synthesis  for  the  Air  Tlaffic  Di^laylColUsion 
Warning  Monitor  Domain  (Burkhard  1992),  which  provides  examples  illustrating  Synthesis 
practices,  nominally  for  the  leveraged  ^thesis  process  in  Part  Lev  of  this  guidebook  but 
representative  in  many  aspects  of  any  Synthesis  process. 

Several  recent  publications  are  of  interest,  not  only  with  respect  to  Synthesis  but  for  reuse  in  general: 

•  Reuse  Adoption  Guidebook  (Software  Productivity  Consortium  1992c),  which  desCTibes  a 
process  by  which  an  organization  can  adopt  a  reuse  process  and  the  factors  that  guide 
definition  of  the  appropriate  process. 

•  Criteria  for  Comparing  Reuse-Oriented  Domain  Anafysis  Approaches  (Wartik  and  Prieto-Dfaz 
1992),  which  discusses  the  factors  that  differentiate  alternative  approaches  to  domain  analysis. 

•  Introducing  Megaprogramming  at  the  High  School  and  Undergraduate  Levels  (Ewa^d  and 
Wartik,  to  be  published  in  1994),  which  describes  a  project  that  worked  with  high  schools  and 
universities  to  develop  curricula  and  materitds  for  introducing  software  reuse  as 
megaprogramming,  in  the  form  of  a  Synthesis  process. 

1.4  DOCUMENT  STRUCTURE 

This  guidebook  is  organized  into  three  parts.  Part  Syn  is  an  overview  of  the  Synthesis  methodology 
and  associated  family  of  processes.  It  includes: 

•  An  introduction 

•  A  desaiption  of  the  context  and  principles  of  a  Synthesis  practice 

•  An  explanation  of  how  a  particular  Synthesis  process  is  derived  compatible  with  the  organization’s 
reuse  capabilities 

This  introduction  defines  standard  notations  and  conventions  used  throughout  all  parts. 

Parts  Opp  and  Lev  are  each  complete  guidebooks  for  a  particular  Synthesis  process.  Part  Opp 
describes  an  opportunistic  Synthesis  process.  Part  Lev  describes  a  leveraged  Synthesis  process.  Each 
of  these  parts  presently  consists  of  four  sections  with  the  fourth  section.  Advanced  Tbpics,  reserved 
for  future  use. 

•  Overview  (OV) 

•  Domain  Engineering  (DE) 


OV.l.  Inuoductioa 


•  Application  Engineering  (AE) 

•  Advanced  Ibpics  (AT) 

An  Overview  section  {nrovides  a  brief  description  of  the  aj^licable  ^thesis  {nrocess  as  a  whole. 

A  Domain  Engineering  section  defines  the  activities  you  follow  to  standardize  the  jx-ocess,  work 
products,  and  practices  of  Application  Engineering  for  a  business-area  organization.  The  activities  o[ 
DomainEngineeringare  orguiized  and  presented  hierardiically  (see  Eample  OV.1-1).  This  hierardiy 
reflects  a  grouping  based  on  the  knoudedge  and  expertise  need^  to  perform  each  activity,  rather  than 
the  order  in  which  activities  may  be  performed.  A  description  of  an  aggregate  activity  is  primarily  a 
summarization  and  roadmap  to  its  si^activities.  Each  aggregate  activity,  as  well  as  each  of  its  suba^- 
vities,  is  described  in  its  own  section.  Each  activity  is  desoibed  according  to  the  outline  shown  in 
Example  OV.1-2. 

An  Application  Engineering  section  defines  a  prototypical  process,  activities,  and  work  products  for 
Application  Engineering.  A  primary  objective  of  Dcnnain  ^igineering  is  to  refine  this  definition  to 
satisfy  the  needs  and  objectives  of  supported  projects.  Each  activity  of  ^plication  Engineering  is 
described  according  to  the  outline  shown  in  Erample  OV.1-2. 

An  Advanced  Ibpics  section  is  reserved  for  future  use  in  presenting  discussions  of  issues  requiring 
advanced  understanding  of  Synthesis.  The  emphasis  of  sudi  discussions  will  be  on  the  refinement  of 
a  Synthesis  process  and  its  guidebook  desoiption  to  meet  particular  needs. 

Some  supporting  material  follows  Part  Lev.  The  Appendix  shows  the  completeness  and  maturity  of 
the  material  in  Parts  Opp  and  Lev.  A  List  of  Abbreviations  and  Acronyms,  Glossary,  and  References 
follow  the  Appendix. 

1.5  USING  THIS  GUIDEBOOK 

This  version  of  the  guidebook  is  intended  as  a  reference  for  practicing  managers  and  engineers.  The 
guidance  can  also  be  tailored  to  reflect  an  organization’s  standard  and  prevailing  software  develop¬ 
ment  methods.  As  a  rule,  detailed  sections  are  meant  to  be  sufficiently  complete  for  full-scale  use.  For 
smaller,  more  exploratory  pUot  projects,  you  may  decide  to  orpend  less  effort  on  activities  related  to 
management,  process  definition,  or  opportunities  for  automation;  however,  no  activities  should  be 
skipped  entirely. 

The  guidebook  is  also  organized  for  use  as  a  graduated  introduction  to  ^thesis.  Areading  of  Section 
2  in  this  Part  and  Sections  DE  and  AE  (in  either  l^t  Opp  or  Part  Lev  as  appropriate)  is  suffident  to 
gain  a  basic  understanding  of  the  concepts  of  ^thesis.  Example  OV.1-1  serves  as  a  guide  to  which 
sections  you  should  read  for  a  deeper  understanding  of  particular  aspects  of  Domain  Engineering. 
You  may  choose  to  skip  sections  lower  in  the  hierardiy  when  more  detail  is  not  of  interest.  This 
hierarcl^  is  valid  for  both  Part  Opp  and  Part  Lev. 

Activity  descriptions  in  the  Domain  Engineering  and  Application  Engineering  sections  are  not 
cookbook  redpes  on  how  to  perform  Synthesis.  The  Synthesis  process  family  is  a  sophisticated  ap¬ 
proach  to  help  solve  a  complex  problem  in  partially  understood  domains  where  the  experienced  engi¬ 
neer  must  use  judgement  and  intuition  to  properly  interpret  Synthesis  for  his  or  her  given  situation. 
The  process  diagrams  found  within  this  guidebook  are  intended  to  aid  the  reader’s  understanding  of 
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Danain  Manageownt  (DE.1.) 


Domain  Analytis  (DR2.) 


Domain  Definition  (DR2.1.) 


Domain  Specification  (DE.2.2.) 


Decision  Model  (DE.2.2.1.) 


Product  Requirements  (PE22JL) 


Process  Requirements  (DE.22J.) 
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Product  Architecture  (DE22A.1 


I 


Domain  Verification  (DE2J.) 


Domain  Implementation  (DK3.) 


Product  Im|Jementation  (DE3.1.) 


Component  Implementation  IDR3.1.1. 
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Itocess  Support  Development  (DEJ^) 


Example  OVl-1.  Hierard^  of  DcHnainEn^neering  Activities 


OV.l.  Introductioii 


1.  Describe  when  tbe  activity  is  relevant  and  can  be  peifoimed. 

•  Objectives:  Explain  the  objectives  that  you  should  achieve  in  the  perfoimanoe  of  this  activity. 

•  Required  information:  Describe  baselined  Synthesis  work  products  or  <Mher  information  upon 
vriiidi  some  or  all  of  the  steps  of  this  activity  d^nd. 

•  Required  knoMedge  and  e^qwrienoe:  Describe  business>area,  domain,  and  general  software 
knoudedge  and  ttqperienoe  you  need  to  effectivety  aocompilish  the  required  tasks  of  this  activity. 

2.  Product  DneriptioH.  Describe  the  work  product  that  results  from  oomidetion  of  the  activity. 

•  Purpose:  Describe  what  is  acoonqdished  by  produdng  this  work  product 

•  Content:  Describe  the  information  content  of  this  work  product 

•  Form  and  structure:  Describe  the  strucriue  of  the  woric  product  and  the  form  in  vriiich  its  ccmtent 
is  to  be  presented. 

•  Verification  criteria:  Describe  how  the  oonsistency/conq>leteness,  correctness,  and  quality  of  the 
work  product  will  be  judged.  Provide  review  questions  and  metrics  that  support  that  evaluation. 

3.  Process  Description.  Describe  a  process  that  adiieves  the  objectives  of  the  activity. 

•  Steps:  Describe  the  actions,  with  associated  inputs  and  results,  that  are  required  to  accomplish 
the  objectives  of  the  activity.  Suggest  heuristics  for  performing  each  step  more  efCectivety. 

•  Risk  management:  Identify  risks  that  may  arise  to  prevent  successful,  timely  completion  of  the 
activity,  and  describe  strategies  for  mitigating  those  risks.  Use  checkpoints,  reviews,  and  metrics 
to  reveal  flaws  and  misconceptions. 

4.  Interactions  With  (Hher  Activities.  Describe  interactions  that  may  occur  with  other  activities  as  a  result 

of  using  a  work  product: 

•  Describe  feedback  to  the  activities  that  provide  required  information  to  this  activity. 

•  Describe  feedback  from  other  activities  concerning  the  adequacy  to  them  of  this  activity’s  work 
product. 

Describe  how  those  interactions  stimulate  product  evolution.  For  each  potential  problem,  describe: 

•  Contingency:  The  nature  of  the  problem  that  may  be  found  in  the  use  of  a  work  product. 

•  Source:  The  activity  that  providesAises  the  work  product  of  concern. 

•  Response:  The  appropriate,  alternative  responses  within  this  activity  to  the  contingency. 

5.  (Reserved  for  future  use  onfy.)Ftovideguic]anoe  on  oonqdex  aspects  of  this  activity  in 

short,  topical  discussions.  More  e:q)ansive  papers  appear  in  the  Advanced  'Rq)ics  section.  Discusses  tai¬ 
loring  to  particular  needs  and  the  use  of  alternative,  immature,  but  potentialfy  more  robust  approaches. 

Examine  OV.1-2.  Activity  Description  Outline 

Srn-6 


^thesis.  The  fvooess  diagrams  are  not  meant  to  be  fcmnal  and  oomplete  prooeis  mnOtU  insmd, 
these  diagrams  depict  only  those  entities  and  relidimiships  in^nrtant  to  die  overaH  qiirit  of  Sjjfttheais. 
0''er  aspects  of  ^thesis  have  been  suj^essed  where  they  were  oonskto-ed  to  be  irrelevant  to  the 
pu,  the  suf^rted  text  Hence,  a  process  diagram's  purpose  is  to  depKt: 

•  Steps,  including  subactivities,  that  make  up  an  activity 

•  The  work  product,  or  component  of  a  work  product,  produced  by  eadi  step 

•  How  work  products  are  used  within  the  activity 

•  Which  other  activities  are  the  primary  users  of  the  work  product  produced  by  the  activity  in 
the  process  diagram 

Conversely,  the  process  diagrams  do  not  show: 

•  Control  (entities  that  constrain/enable  performance  of  the  activiQr  or  its  steps) 

•  Mechanisms  (roles  that  perform  the  steps  of  the  activity  and  methods  that  support  that 
performance) 

•  Feedback^nteraction  within  or  among  activities 

Iteration  within  an  activity  and  between  other  ^thesis  activities  is  determined  by  the  management 
method.  Iteration  is  only  indicated  in  the  top-level  process  diagram  (Figure  OV.2-1  in  the 
Fundamentals  Section)  to  suggest  evolution  of  the  domain  as  as  wiiole. 

Partial  examples  of  work  products  are  sometimes  presented  in  the  t«tt  to  illustrate  the  form  and 
content  of  individual  Synthesis  work  products.  These  examples  contain  fragments  of  Domain  Engi¬ 
neering  work  products  drawn  from  the  Traffic  Light  Control  Software  System  (TLC)  domain.  ATLC 
^tem  controls  and  coordinates  the  operation  of  traffic  lights  at  a  given  intersection. 

1.6  CONVENTIONS  AND  NOTATION 

This  guidebook  uses  the  following  ^pographic  conventions: 


Serif  font .  General  presentation  of  information. 

Capitalized  Serit  fon?  .  Names  of  %nthesis  work  products  and  activities. 

Italicized  serif  font .  Mathematical  expressions  and  publication  titles. 

Boldfaced  serif  font . Section  headings  and  emphasis. 

Bol^aced  italicized  serfffont .  Run-in  headings  in  bulleted  lists  and  low-level  titles  in  the 

process  sections  of  guidebooks. 

Typewriter  font . Syntax  of  code. 

{  } .  Alternative  items  (one  or  more). 
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[  ]  .  Optional  items  (zero  OT  one). 

I .  Separator  for  a  list  of  alternatives. 


In  this  guittebook,  figures  that  dejnct  a  process  diagram  use  the  following  symbols: 


Activity  or  step  named  X. 


CI> 


Product  or  work  product  named  Y. 


r - '  or  . . . Alogicalgrou|Mngof  activities  or  steps. 

ItaUdzed  serif  tom  .  An  activity  outside  the  context  of  the  particular  figure. 

- > .  A  relationship  between  activities  or  steps  and  the  work 

produces)  that  are  inputs  to  or  results  of  those  activities  OT 
steps. 


— > .  A  relationship  between  activities  showing  additional 

interaction  or  information  communicated  between  those 
activities. 


Work  product  examples  in  this  guidebook  use  a  metaprogramming  notation  to  represent  variability 
in  a  product.  Variability  in  a  product  means  that  a  product  will  have  different  content,  depending  on 
certain  critical  decisions.  A  metaprogramming  notation  allows  you  to  descnbe  how  a  ivt^uct’s  con* 
tent  is  determined  by  those  decisions.  A  simple  example  of  this  is  the  use  of  a  maao  jvocessor  to  defer 
a  decision  about  the  size  of  a  data  structure.  Instead  of  making  the  decision  on  the  size  of  the  structure 
when  the  code  is  written  (by  embedding  a  constant),  you  can  defer  the  decision  Ity  setting  parameters 
for  (parameterizing)  the  code  and  supplying  the  required  value  at  compile  time.  A  metaprogramming 
notation  is  an  extension  of  this  idea. 


Boldfaced,  bracketed  text  is  used  for  metaprogramming  notation  in  this  guidebook: 

<boldfiiced_identifier> .  A  deferred  dedsion  (e.g.,  <si»>).  Sudi  identifiers  may 

be  separated  Ity  dots  to  indicate  elements  of  composite  de¬ 
cisions  (e.g.,  <stack.type>  and  <staclusize>).  This  iden¬ 
tifier  is  retraced  with  the  actual  value  df  Ae  dedsion 
whenever  an  instance  of  a  work  product  is  created. 

<if  predicate  then>  bodyl  [<else>  lxxty2]  <en<fif>  . 

A  conditional  indudon.  If  the  {vedicate  evaluates  to  true, 
then  bottyl  is  induded  in  the  work  product.  If  an  else  dause 
is  indud^  and  the  {vedicate  evaluates  to  false,  then  body2 
is  included  in  the  work  jvoduct  The  predicate  is  informal 
and  defined  in  terms  of  decisions.  Also  referred  to  as  a 
conditional  term. 

<forall  ident  in  list>  body  <endfor>  An  iterative  (repeating)  indusion.  The  list  is  an  identifier 

for  a  dedsion  that  is  multivalued.  This  construct  indudes 


(me  copy  (tf  body  in  the  work  product  fi>r  each  value  of  the 
decbk^  Fbr  each  of  body  included,  the 

corresponding  decision  value  rejdaoes  all  occunences  of 
identifier  ident  in  that  copy.  Also  referred  to  as  an  iterative 
term. 

A  bcxly  is  any  text  that  may  be  a  part  o(  sc»ne  work  product.  A  bcxfy  may  also  ccmtain  nested 
metaprogramming  constructs:  if  so,  those  constnicts  must  be  evaluated  to  determine  the  content  of 
the  body. 
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OV2.  FUNDAMENTALS  OF  SYNTHESIS 

^thesis  was  conceived  in  recognition  of  past  eaq)erience  that  suggested  a  need  fot  a  majcn’ 
reconceptitm  of  the  software  process  (Canq4^  and  Wdss  1990)  to  produce  in^iroveinents 
in  software  {voductMty,  product  q^Qr,  mani^eabiliQr,  and  customs  r^xxmveness.  Davis, 
Bers(^  and  Omun  (1968)  presentacomparisonofsevml  models  of  the  scrftwve  development  life 
cycle,  whidi  is  a  good  framework  for  understanding  this  need  As  the  foundation  fOT  an  initial  under- 
standing  of  S^thesis,  this  section  describes  die  principles  undo-lying  the  ^the^  approadi,  dis¬ 
cusses  the  conteit  in  adiidi  Syndiesis  iqjpiies,  and  provides  an  overview  of  how  Synthesis  wOTks,  both 
in  general  and  at  the  stages  of  reuse  program  implementation  for  \diich  examine  ^thesis  processes 
have  been  defined. 

2.1  KEY  PRINCIPLES 

The  Synthesis  concept  depends  on  four  basic  prindides:  program  families,  iterative  {Mxicesses, 
specifications,  and  abstraction-based  reuse.  An  understanding  of  these  prindides  will  help  you  to 
understand  Synthesis. 

2.1.1  Program  Families 

A  program  family  is  a  set  of  fvograms  that  are  sufiBdently  similar  that  it  is  wortlnt^e  to  understand 
the  common  properties  of  the  set  before  considering  the  special  properties  of  individual  instances. 
The  concept  of  program  families  was  first  proposed  Dijkstra  (1972)  and  later  elaborated  by  Famas 
(1976).  Both  piqiers  argue  that  developers  should  construct  software  programs,  not  as  unique  arti¬ 
facts,  but  as  instances  of  a  family  of  similar  {n-ograms.  A  {nrimary  distinction  of  this  view  is  in  how  the 
creation  of  program  versions  are  viewed:  not  as  successive  mocMcations  to  previous  versions,  but  as 
rederivations  from  a  common  abstraction.  Each  member  of  a  family  can  be  diaracterized  entirely  in 
terms  of  how  it  differs  from  the  commcm  abstraction  (i.e.,  the  variations  in  the  family).  In  ^tiiesis, 
this  concept  of  (vrigram  families  is  generalized  to  a  concept  of  product  families  that  encompass  all  the 
work  products  of  sc^tware  development. 

2.1.2  iTERATivB  Processes 

An  iterative  jn-ocess  is  a  process  in  ^ch  work  products  are  considered  complete  only  after  repetition 
of  producing  and  using  activities.  Eadi  iteration  is  short  with  goals  set  to  make  i»-ogress  toward  an  end 
product  without  unnecessary  aqx>sure  to  risk  of  failure  if  short-term  goals  are  not  met.  In  a  nonitera¬ 
tive  process,  an  activity  continues  without  interruption  until  its  resulting  work  {Hoducts  are  believed 
comj^ete.  Only  after  sudi  proclaimed  comfdetion  is  there  any  attempt  to  use  t^e  work  products  in 
performing  ot^r  activities.  Although  {banning  (k>es  not  provide  for  rework  of  the  results,  feedback 
from  using  activities  inevitably  requires  rejrianning  to  allow  for  corrections;  sdiedule  and  quality  are 


usually  deluded  as  a  result.  Since  many  errors  in  software  work  {xoducts  are  difficult  to  discover 
without  feedbadt  from  detailed  use,  an  iterative  process  ^tematic^  {vodtwes  better  quality  results 
than  a  process  that  depends  on  producing  correct  work  products  witluMt  sudi  repetition.  A  strong  dis¬ 
cipline  of  work  product  versioning  and  configuratitm  management  is  crudal  to  a  successful  iterative 
pMTOcess  (Humphrey  1989). 

2.1J  SPBCIFIOaiONS 

A  specification  is  a  compdete,  pvedse  descrip)tion  of  the  verifiable  properties  required  of  a  work 
product  or  set  of  work  pMroducts  (e.g.,  a  complete  sctftware  piroduct).  a  system,  a  sp)edficati(»i  can 
serve  as  an  abstract  m^el  that  aids  understanding  and  analysis,  expH-essive  |x>wer,  the  notation 
in  uiiidi  a  spedfication  is  written  usually  assumes  an  understanding  of  sp>edaliz^  terminology  and 
constructs.  Normally,  a  sp)ectfication  is  either  a  descrip)ti(»i  of  requirements  (i.e.,  the  problem  to  be 
sdved)  or  a  description  o(  a  design  (Le.,  the  form  and/or  content  oi  a  solution),  /^tkmally  in  ^diesis, 
a  sp>ecification  may  describe  a  product,  or  work  piroduct,  (i.e.,  a  pn-oblem  and  its  solution)  by  resolving 
the  variations  that  characterize  a  family  of  such  (work)  products. 

This  concept  of  sp)edfications  derives  from  work  in  both  requirements  sptedfication  and  automatic 
programming.  A  key  objective  in  both  areas  is  the  aeation  of  a  notation  for  describing  a  required  sys¬ 
tem  without  unduly  constraining  the  details  of  the  solutioiL  The  Naval  Research  Laboratory  Software 
Cost  Reduction  project  develop)ed  an  ap^oach  to  px^edse,  semi-formal  specifications  of  software  re¬ 
quirements  for  avionics  systems  (Heninger  et  al.  1978).  ^nograd  (1979)  argues  the  need  for  a  new 
view  of  programming  based  on  a  desaiptive  (i.e.,  nonprescriptive)  language.  Balzer  and  Goldman 
(1979)  desaibe  aiteria  for  designing  and  jud^ng  the  quality  of  a  spedfication  language. 

2.1.4  Abstraction-Based  Reuse 

The  direct  result  of  a  software  developnnent  project  is  a  set  of  wwk  products  that  describe  and  implnnent 
a  software  solution  to  a  customer-defined  problem.  Abstraction-based  reuse  (Campbell  1989)  pro¬ 
vides  a  means  for  representing  a  product  family  as  a  set  of  adaptable  work  products  and  for  deriving 
instances  of  each  work  p)roduct  to  produce  a  pjarticular  system  p>roduct.  An  adaptable  work  product 
oondsely  represents  a  family  of  similar  work  products  that  vary  in  well-defined  ways.  This  sup)px}rts 
the  localizing  of  potential  changes  so  that  the  cost  of  modification  or  reuse  is  minimized  for  likely 
changes. 

The  Ada  generic  p)adkage  is  a  notation  for  representing  a  family  of  similar  Ada  code  padtages.  Most 
word  processing  p}ackages  provide  a  "form  letter”  capnbili^  that  can  be  used  to  represent  a  family  of 
documents.  Metaprogramming  tools,  such  as  TRF*,  provide  a  flexible  notation  for  representing  fami¬ 
lies  of  text-based  work  products.  Each  of  these  medianisms  provides  a  fadlity  for  produdng  work 
products  from  a  representation  of  a  work  product  family. 

2.2  CONTEXT  FOR  SYNTHESIS 

In  initiating  a  ^thesis  practice,  you  should  first  consider  the  context  in  whidi  you  currently  work. 
This  contot  is  determined  by  three  concerns:  business  objectives,  ^tem  engineering  practices,  and 
the  objectives  of  a  software  engineering  process.  Ihese  concerns  constrain  the  typ}e  of  Synthesis  pro¬ 
cess  that  an  organization  can  adopt,  ^thin  this  context,  you  can  create  a  cap)adty  for  rapid,  systematic 
delivery  of  similar,  yet  varied,  systems. 

*  TRF  »  a  meUprogramtning  tod!  developed  by  Template  Software,  Inc. 
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2J.1  Business  Objectives 

Synthesis  is  diaracterized  by  its  foois  on  a  family  of  systems  for  a  business  area  rather  than  on 
i^vidual  systems.  This  focus  arises  from  evidence  that,  within  a  class  of  systems,  an  understandiiig 
of  similarities  provides  significant  leverage  for  constructing  a  great  variety  of  high-quality  systems 
cheaply  and  reliably. 

>Mth  Synthesis,  you  otnceive  a  domain  not  on  an  objective  basis,  but  as  a  realization  of  the  declared 
business  objectives  of  your  specific  organization.  Your  business  objectives  determine  the  types  of 
systems  you  build  and  who  your  customers  are.  A  primary  consideration  in  setting  these  objectives  is 
the  expertise  alreatfy  available  within  your  organization,  particularly  as  a  result  of  otperience  in  build¬ 
ing  systems  in  the  past.  Other  considerations  are  your  expectations  of  future  customer  needs  and 
chan^ng  technology. 

The  enviroiunent  most  conducive  to  the  effective  use  of  Synthesis  is  one  in  whidi  you  give  emphasis 
to  long-term  business  objectives.  A  positive  climate  for  investment  in  the  future,  possibly  at  the  cost 
of  deferred — but  potentially  greater — total  return  is  a  major  advantage  for  realizing  success  with 
Synthesis.  It  is  important  to  consider  these  larger  business  concerns  when  addressing  the  needs  of  a 
particular  customer  to  avoid  arbitrarily  sacrificing  longer-term  interests  to  short-term  pressures.  On 
the  other  hand.  Synthesis  lends  itself  to  a  management  philosophy  of  incremental  commitment,  both 
for  early  pay-back  after  a  minimum  initial  investment  and  for  accommodating  the  changing  needs  of 
a  single  customer  or  the  differing  needs  of  many. 

2.2.2  System  Engineering  Practices 

Construction  of  modern,  complex  systems  is  a  major  undertaking  that  often  requires  the  coordination 
of  many  large  groups  of  engineers  with  expertise  in  diverse  fields.  Some  of  these  groups  may  be  organi¬ 
zations  in  separate  companies,  working  jointly  or  as  subcontractors,  to  deliver  a  required  system.  Engi¬ 
neers  follow  a  discipline  of  system  engineering,  in  part  to  partition  the  problem  and  apply  appropriate 
expertise  to  solve  each  facet  of  the  problem  most  effectively.  This  partitioning  into  subsystems  often 
follows  the  lines  of  major  hardware  components,  but  it  may  also  serve  the  purpose  of  decomposing 
the  system  into  more  manageable  software  assemblies. 

Such  partitioning  is  compatible  with  Synthesis,  particularly  when  you  are  able  to  follow  a  systematic 
approach  that  results  in  similar  partitionings  of  similar  systems.  Each  software  partition  (or  subsys¬ 
tem)  then  corresponds  to  a  member  of  a  family  of  similar  subsystems  (i.e.,  software  systems)  that  can 
be  the  responsibility  of  a  cohesive  business  organization. 

2.23  Objectives  OF  A  Software  Engineering  Process 

The  broad  purposes  of  a  software  engineering  process  may  be  stated  simply: 

•  Analysis,  lb  allow  customers  and  developers  to  communicate  effectively  so  that  the  problem 
to  be  solved  is  understood. 

•  Synthesis,  lb  allow  developers  to  produce  a  solution  that  corresponds  precisely  to  the  problem 
as  communicated. 

•  Evolution,  lb  allow  developers  and  customers  to  validate  the  solution  as  having  satisfied  the 
actual  problem. 
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•  Managanoa.  Tb  allow  developers  to  organize  and  coordinate  their  work  as  a  team  for  efficient 
and  elective  performanco  of  the  process. 

A  conventional  approach  to  software  development  achieves  these  purposes,  but  not  effidently. 
Synthesis  is  motivated  by  the  need  for  a  systematic  ap{»oadh  to  tailoring  the  software  engineering 
process  to  meet  the  sp'.cific  needs  of  each  organization.  The  key  to  achieving  this  end  is  to  consider 
long-term  business  needs  when  developing  software.  Looking  first  at  the  similarities  among  systems 
that  your  organization  builds  provides  a  basis  for  you  to  become  more  productive  eliminating 
redundant  effort.  Your  efforts  to  build  a  particular  software  system  can  be  focused  more  efficiently 
on  the  aspects  of  that  system  that  are  distinctive.  Synthesis  prescribes  the  work  that  is  necessary  to 
achieve  this  potential. 

23  AN  OVERVIEW  OF  SYNTHESIS 

The  purpose  of  a  Synthesis  process  is  to  help  you  better  utilize  your  expertise  about  a  set  of  similar 
problems  and  associated  solutions  pertinent  to  your  business  area.  By  viewing  similar  f^oblems  as  a 
family,  common  characteristics  provide  leverage  in  building  any  particular  system.  Similarities  sup¬ 
port  a  form  of  standardization  that  enables  systematic  adaptation  to  meet  the  specific  needs  of  a  par¬ 
ticular  customer.  The  results  of  standardized  decision  making  by  project  engineers  guide  appropriate 
adaptations  of  standardized,  reusable  work  products. 

The  primary  distinguishing  features  of  a  Synthesis  process  are: 

•  Formalization  of  a  domain  as  a  family  of  systems  that  share  many  conunon  features,  but  that 
also  vary  in  well-defined  ways 

•  System  building  reduced  to  resolution  of  requirements  and  engineering  decisions, 
representing  the  variations  characteristic  of  a  domain 

•  Reuse  of  software  artifacts  through  mechanical  adaptation  of  components  to  satisfy 
requirements  and  engineering  decisions 

•  Model-based  analyses  of  described  systems  to  help  understand  the  implications  of 
system-building  decisions  and  to  evaluate  alternatives 

Tne  degree  to  a  Synthesis  process  actually  esdubits  these  features  depends  on  the  needs  and  abilities 

of  the  adopting  organization.  As  a  general  rule,  these  are  goals  that  guide  the  formulation  of  a  Synthesis 
pi 'cess  but  they  may  be  moderated  to  formulate  a  process  that  suits  eadi  organization’s  drcumstances. 

Regardless  of  your  specific  circumstances,  a  Synthesis  process  is  one  which  is  designed  to  support  two 
independent  but  interrelated  objectives: 

•  Tb  produce  and  deliver  software  systems 

•  Tb  increase  the  productivity,  product  qualiQr,  manageabilify,  and  responsiveness  of  software 
production  and  delivery 

Tb  address  these  separate  concerns  most  effectively,  a  Synthesis  process  consists  of  two  integrated 
subprocesses:  Application  Engineering  and  Domain  Engineering.  Figure  OV.2-1  shows  how  these 
processes  relate  to  each  other. 
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Application  Engineering  (described  further  in  Seoion  AE  of  Farts  Opp  and  Lev)  is  a  standardized 
process  by  which  projects  produce  and  deliver  applications  to  customers.  In  terms  of  objectives,  this 
is  the  equivalent  of  conventional,  ''one-of-a-kind”  software  develoiMnent.  Both  conventional  and  Syn¬ 
thesis  approaches  start  with  customer  requirements  and  produce  a  set  of  software  work  products  that 
are  meant  to  satisfy  those  requirements.  However,  in  a  ^thesis  aj^oadi,  through  a  process  of  Do¬ 
main  Engineering  (desaibed  further  in  Sedion  D£  of  Farts  Qpp  and  Lev),  you  can  institute  a  simpler, 
more  efficient  process  of  software  development  and  support  it  with  standardized,  reusable  work 
products. 

Whether  Application  Engineering  is  a  series  of  analysis,  design,  implementation,  and  testing  activities 
or  creating  and  validating  a  model  to  generate  a  required  application,  it  focuses  on  requirements  and 
engineering  decisions  that  are  sufficient  to  describe  a  particular  system,  given  a  family  of  such  systems. 
Work  products,  including  code  and  documentation,  are  medianically  derived  from  these  decisions 
using  adaptable  forms  of  those  work  products  provided  by  Domain  Engineering. 

Domain  Engineering  supports  ^plication  Engineering  in  two  ways.  First,  it  creates  a  set  of  adaptable 
work  products  that  correspond  to  ffie  work  {voducts  that  an  application  engineering  project  must  pro¬ 
duce.  By  identifying  key  decisions  that  are  deferred  until  a  particular  ^tem  is  needed  and  parameter¬ 
izing  a  work  product  to  show  how  it  varies  as  a  result  of  those  decisions.  Domain  Engineering  creates 
work  products  that  are  adaptable  to  subsequent  Application  Engineering  dedsions.  Second,  Domain 
Engineering  describes  a  standard  implication  Engineering  process  that  supports  the  decision  making 
and  the  work-product  CTeation  appropriate  to  {^ojects  in  the  business  area.  The  process  definition 
institutes  standard  procedures  and  practices  viiidi  Domain  Engineering  may  augment  with 
appropriate  automated  support. 

Domain  Engineering  and  Application  Engineering  are  iterative  processes  to  attain  quality  products 
and  to  support  evolving  needs.  Application  Engineering  must  accommodate  uncertain  and  changing 
customer  requirements.  Domain  Engineering  must  acccmimodate  dianging  markets,  as  well  as  the 
evolving  product  and  process  needs  of  dient  apj^ication  engineering  projects. 
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2.3.1  Defining  A  Tailored  Process 

To  adopt  a  reuse  process  (such  as  a  Synthesis  process),  you  need  to  identify  one  that  suits  your 
organization’s  nee^  and  abilities  for  reuse.  A  key  element  of  reuse  adoption  is  to  understand  the  na¬ 
ture  and  extent  of  your  organization’s  current  needs  and  capacity  for  reuse  and  develop  a  plan  for  im¬ 
provements  in  your  reuse  capability.  The  Consortium’s  Reuse  Capability  Model  (RCM),  described 
in  the  Reuse  Adoption  Guidebook  (Software  Productivity  Consortium  1992c),  is  a  mechanism  for  this 
purpose. 

The  RCM  provides  a  framework  for  deriving  a  definition  of  a  reuse  process  that  matches  your 
organization’s  circumstances.  Every  Synthesis  process  embodies  the  same  basic  principles.  However, 
each  can  differ  based  on  the  degree  to  which  the  adopting  organization  chooses  to  commit  to  the  vari¬ 
ous  success  factors  for  improved  reuse  capability  that  the  RCM  defines.  Success  factors  are  grouped 
into  four  categories,  reflecting  different  perspectives  on  reuse  that  are  important  to  an  organization: 

•  Management.  Factors  pointing  to  of^rtunities  for  improving  management’s  role  in  fadlitating 
reuse. 

•  Application  Devdopment.  Factors  pointing  to  opportunities  for  improving  the  utilization  of 
reusable  assets  in  the  development  of  end-products. 

•  Asset  Development.  Factors  pointing  to  opportunities  for  improving  how  assets  are  acquired  or 
developed  for  reuse. 

•  Process  and  Technology,  Factors  pointing  to  opportunities  for  improving  the  effectiveness  of  the 
software  development  process  and  its  use  of  appropriate  technology. 

As  noted  in  describing  the  distinguishing  features  of  a  Synthesis  process  (at  the  start  of  Section  2.3), 
the  form  of  any  specific  process  depends  not  just  on  those  features  but  on  the  needs  and  abilities  of 
the  adopting  organization  as  well.  An  organization  with  unlimited  abilities  could  adopt  a  Synthesis 
process  that  exhibited  those  features  clearly;  a  more  limited  organization  would  adopt  a  process  that 
did  not  require  all  of  the  abilities  that  these  features  require.  A  Synthesis  process  as  a  whole  is  affected 
by  management  factors  and  process  and  technology  factors  of  the  RCM.  TTie  Application  Engineering 
process  is  further  affected  by  application  development  factors.  The  Domain  Engineering  process  is 
further  affected  by  asset  development  factors. 

By  considering  the  needs  and  abilities  of  your  organization  with  respect  to  each  of  the  RCM  success 
factors,  you  can  design  a  process  suited  to  that  organization.  As  a  guide  to  incrementally  improving 
your  organization’s  reuse  capability  and  the  implementing  process,  the  RCM  includes  an  implementa¬ 
tion  model  consisting  of  four  stages  through  which  an  organization’s  reuse  practice  can  evolve  from 
an  initial,  ad  hoc  reliance  on  the  initiative  of  individual  engineers: 

•  Opportunistic.  Project  plans  allow  for  reuse;  reusable  assets  are  identified  to  support  the 
separate  CTeation  of  individual  work  products;  effort  is  focused  on  the  immediate  needs  of 
current  projects. 

•  Integrated.  Reuse  is  an  integrated  element  of  the  standard  development  process;  assets  are 
developed  to  enable  multiple  use  based  on  current  needs. 
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•  Leveroged.  Assets  are  developed  for  reuse  considering  both  current  and  likely  future  needs 
across  a  {H^oduct  line.  Projects  are  viewed  as  agents  of  a  business-area  organization  and  work 
to  gain  maximum  leverage  from  and  enhance  the  supported  domain. 

•  Anticipating.  The  potential  for  reuse  is  a  primary  consideration  in  how  [voblems  are  viewed. 
New  business  opportunities  are  sought  and  evaluated  in  terms  of  how  well  they  e^oit  avail¬ 
able  reusable  assets.  Each  project  is  initiated  with  an  understanding  of  how  its  problem 
corresponds  to  problems  previously  solved. 

An  organization  may  progress  incrementally  through  these  stages  of  implementation  for  lower  risk 
or  it  may  commit  direct  to  the  adoption  of  a  more  advanced  stage  to  get  corresponding  benefits  sooner. 

Part  Opp  of  this  guidebook  describes  a  Synthesis  process  that  is  oriented  to  the  opportunistic  stage 
of  reuse  implementation.  Part  Lev  describes  a  ^thesis  process  that  is  oriented  to  the  leveraged  stage. 
Other  Synthesis  processeses  could  be  defined  at  the  integrated  or  anticipating  stage.  Depending  on 
your  organization’s  circumstances  concerning  reuse,  you  are  likely  to  prefer  one  of  these  processes 
over  the  others.  Any  such  process  definition,  however,  is  best  viewed  as  a  {arototype  from  vdtidi  you 
should  derive  a  process  that  is  tailored  to  your  spedfic  circumstances.  The  remainder  of  this  section 
characterizes  the  RCM  and  Synthesis  processes  in  relation  to  each  of  the  ROM’s  four  implementation 
stages. 

The  two  Synthesis  processes  described  in  this  guidebook  are  appropriate  to  organizations  that  are 
targeting  either  the  opportunistic  or  the  leveraged  stage  of  implementation.  Each  process  has  been 
designed  to  reflect  the  assumptions  and  limitations  appropriate  to  the  targeted  stage  of  instituting  a 
reuse  program.  For  example,  at  the  opportunistic  stage,  application  engineers  find  and  evaluate  reus¬ 
able  components  specifically  for  each  work  product.  At  the  leveraged  stage,  reuse  by  application  engi¬ 
neers  is  indirea  in  terms  of  requirements-level  variations  and  leads  implicitly  to  integrated  reuse 
across  the  work  products  that  constitute  the  product.  This  difference  is  traceable  to  success  factors 
identified  respectively  with  these  stages  in  the  RCM.  Sections  2.3.2  through  2.3.5  describe  the  success 
factors  that  guide  the  design  of  a  Synthesis  process  appropriate  to  a  particular  RCM  stage  of 
implementation. 

23.2  An  Opportunistic  Synthesis  Process 

Your  organization  can  adopt  an  opportunistic  Synthesis  process  if  it  is  targeting  a  new  state  of  practice 
similar  to  the  following: 

•  Management.  In  planning  an  application  engineering  project,  project  management  makes 
allowance  for  reuse  of  existing  work  products.  Project  engineers  are  expected  to  reuse  existing 
work  products  or  components  appropriately  without  special  support  or  coordination.  Domain 
Engineering  is  managed  separately  with  the  goal  of  increasing  opportunities  for  reuse. 

•  Application  Development.  Application  Engineering  is  work  product  oriented,  as  in  conventional 
practice.  When  creating  an  assigned  work  product,  it  is  the  engineer’s  responsibility  to  recog¬ 
nize  and  exploit  opportunities  for  reuse  of  existing  relevant  components,  particularly  those 
provided  by  Domain  Engineering. 

•  Asset  Devdopment.  Domain  Engineering  analyzes  previously  developed  work  products  to  find 
components  to  combine  and/or  refine  in  ways  that  increase  opportunities  for  their  reuse.  The 
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known  needs  of  active  or  impending  apf^cation  engineering  jvojet^  guide  this  analysis  and 
implementation. 

•  Process  and  Technology,  The  ^)plication  Engineering  process  is  not  substantially  changed  to 
accommodate  reuse.  A  Domain  Engineering  process  is  an  adaptation  of  that  process.  Eristing 
off-the-shelf  technolt^,  such  as  Ada  generics  and  word  processing  packages,  may  be  used  to 
create  adaptable  work  products  or  components  (Le.,  families). 

At  the  opportunistic  stage  of  implementation,  the  ^plication  Engineering  process  is  organized  and 
managed  in  a  conventional  manner.  The  emphasis  is  still  on  the  develojanent  of  "one-of-a-kind”  sys¬ 
tems  and  the  phased  completion  and  review  of  corresponding  deliverable  work  products.  For  example, 
DOD-STD-2167A  (Department  of  Defense  1988)  has  traditionally  been  interpreted  as  a  "waterfall” 
model,  leading  through  a  series  of  phases,  such  as  software  requirements  analysis,  preliminary  design, 
and  detailed  design.  An  opportunistic  reuse  process  has  the  following  unifications  for  an  oiganization: 

•  Reuse  is  a  responsibility  of  individual  engineers  as  they  produce  assigned  work  products. 
Domain  Engineering  attempts  to  provide  families  of  work  products  (as  a  whole  or  in  parts) 
that  consolidate  past  experience  in  building  similar  systems  in  the  domain.  It  is  left  to  each 
engineer  to  decide  when  there  is  sufficient  opportunity  for  reuse. 

•  Domain  engineering  and  application  engineering  projects  are  managed  independently.  The 
immediate  needs  of  projects  to  satisfy  customer  requirements  override  any  longer  term  objec¬ 
tives  for  the  domain.  When  conflicts  arise.  Domain  Engineering  gives  priority  to  supporting 
immediate  project  needs.  Whenever  possible,  those  needs  are  satisfied  in  a  way  that  comes 
closest  to  matching  long-term  objectives. 

An  opportunistic  reuse  process  is  one  in  which  reuse  efforts  are  oriented  entirely  to  supporting  the 
Client  needs  of  a  business  group’s  active  (and  imminent)  application  engineering  projects.  An  oppor¬ 
tunistic  Synthesis  process  is  directed  toward  increasing  the  opportunities  for  effective  retise  without 
causing  significant  changes  in  the  application  development  process  already  familiar  to  managers  and 
engineers. 

In  opportunistic  Synthesis,  a  project  follows  its  normal  process  (similar  to  that  of  Figure  OV.2-2,  which 
was  derived  following  Evolutionary  Spiral  Process  [ESP]  guidtmce),  changed  only  by  the  addition  of 
general,  low-level  guidelines  for  individual  engineers  to  find  and  exploit  relevant  reusable  assets.  Do¬ 
main  Engineering  (Figure  OV.2-3)  is  an  attempt  to  identify,  organize,  and  improve  assets  fi-om  pre¬ 
viously  built  systems  (a  key  element  of  domain  kno^edge)  so  that  those  assets  will  be  useful  in  satisfy¬ 
ing  engineers’  current  needs.  Because  Application  Engineering,  at  this  stage  of  reuse  program 
implementation,  emphasizes  the  direct  creation  of  documents  and  code.  Domain  Management  fo¬ 
cuses  Domain  Engineering  efforts  on  opportunities  for  standardizing  the  form  and  content  of  particu¬ 
lar  work  products.  The  domain  engineer  identifies  sets  of  similar  work  products,  defines  each  set’s 
common  and  varying  features,  and  uses  those  features  to  represent  the  set  as  a  family  from  which 
application  engineers  can  extract  instances. 

An  Integrated  Synthesis  Process 

Your  organization  can  adopt  an  integrated  Synthesis  process  if  it  is  targeting  a  new  state  of  practice 
similar  to  the  following: 
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•  Management.  Management  recognizes  that  application  engineering  projects  share  a  common 
base  of  domain  expertise.  Domain  and  appUcation  project  planning  are  integrated  to  avoid 
duplicate  effort  and  ensure  timely  domain  support  for  critical  application  project  needs.  The 
domain  supports  project  needs  and  objectives  as  long  as  those  needs  and  objectives  fit  with  the 
accepted  domain  scope  and  domain  resources  suffice. 


•  Application  Development.  An  Apfdication  Engineering  process  is  work-product  oriented  but 
application  engineers  expect  to  tw  able  to  produce  a  reasonable  apprcndmation  of  the  deliver¬ 
able  product  from  an  ^plication  Model  and  Adaptable  Components  and  CTeate  the  final 
product  without  major  structural  rework.  A  unified  core  .^)plication  Model,  with  extensions 
specific  to  each  work  product,  drives  production  of  all  required  work  products. 
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Figure  OV2>3.  A  DomamEagineeiiiig  Process  for  OppottuniitieReuM(Siinplifie(Q 

•  j^set  Devdopment.  Every  required  application  en^eering  work  product  is  reivesented  as  a 
family.  Whenever  there  are  similar  variations  in  related  work  products,  there  is  a  common 
source  of  variability  to  which  traoeabQity  is  maintained.  Both  the  >^>i^cation  Engineering 
product  family  and  the  associated  process  are  tailored  to  the  nee^  of  active  projects. 
Problems  due  to  Domain  Engineering  are  tradced  and  used  to  motivate  enhancements. 

*  Avccss  and  TbcAnoHogy.  The  Domain  Engineering  and  y^^cation  Engineering  processes  are 
integrated  with  explicit  domain  support  for  active  application  projects  and  specific  feedbadc 
on  needs  from  those  projects  to  Domain  Engineering,  ^^lication  Engineering  relies  (m 
Domain  Engineering  tedmology  accept  with  exfdidt  waivers. 

At  the  integrated  stage  of  implementation,  the  advantages  of  leveraged  effort  compete  with  the 
immediate  concerns  of  individual  projects.  Sdution  approadies  that  can  build  on  existing  assets  are 
preferred  over  unique,  single-use  solutions.  The  long-term  needs  of  the  business  organization  influ¬ 
ence  dedsions  on  the  near-term  use  of  resources.  Although  apf^cation  [vojects  may  still  have  to 
perform  one-of-a-kind  effort,  it  is  easier  to  distinguish  essential  from  arbitrary  product  variations. 

Application  Engineering  and  Domain  Engineering  processes  typical  of  an  integrated  Synthesis 
practice  have  not  yet  been  defined. 

2J.4  A  Leveraged  Synthesis  Process 

Your  organization  can  adopt  a  leveraged  Synthesis  jn’ocess  if  it  is  targeting  a  new  state  of  practice 
similar  to  the  following: 
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«  ManagemmL  Management  views  a  business  organization  as  a  vehide  for  buildiqg  i^fstems  in 
a  diosen  problem  domain.  Management  of  the  domain  and  its  dient  apf^catimi  engineering 
projects  is  unified.  Projects  are  initiated  in  a  particular  organization  vdien  a  problem  fits  pr<^ 
erly  within  its  donuiin.  Domain  Engineering  objectives  consider  project  objectives  but  are 
motivated  predominantly  by  the  need  to  achieve  strat^c  business  objectives. 

•  Ap^caHon  Devdopment,  ^)pUcation  engineers  specify  a  problem  and  its  solution  in  the  form 
of  an  Ai^licadon  Model.  Changes  in  the  problem  or  chafes  in  its  understanding  or  alterna¬ 
tive  solutions  lead  to  a  modified  Application  Model.  Deliverable  work  [X'oducts  are  generated 
directly  from  an  ^plication  Model  and  Adaptable  Components.  Normally,  Domain  Engi¬ 
neering  handles  disaepandes  in  a  product;  occasionally  (e.g.,  when  project  constraints  con¬ 
flict  with  domain  objectives),  Application  Engineering  directly  modifies  generated  work 
products. 

•  Asset  Development.  Development  focuses  on  supporting  a  unified  product  family  that 
comprises  families  of  deliverable  and  supporting  work  products.  Domain  Engineering  gives 
application  engineering  projects  an  abiUty  to  derive  a  product  entirely  from  a  model 
representing  requirements  and  engineering  dedsions  and  reusable  work  product  families. 

•  Process  and  Technology.  Domain  Engineering  creates  a  standard,  reuse-oriented  Application 
Engineering  process  for  projects  in  the  domain.  Key  aspects  of  that  process  are  supported  by 
spedally  built  automation. 

At  the  leveraged  stage  of  implementation,  the  ^plication  Engineering  process  is  organized  and 
managed  in  a  standardized  way  based  on  the  nature  of  the  business  as  determined  by  Domain  Engi¬ 
neering.  The  emphasis  is  on  producing  and  delivering  systems  that  meet  the  needs  of  customers;  how¬ 
ever,  only  systems  that  fit  the  strategic  charter  of  the  organization  are  initiated.  This  process  has  the 
following  implications  for  an  organization: 

•  The  core  expertise  of  the  business  is  focused  on  effective  domain  engineering,  ^plication 
engineering  projects  are  agents  of  the  domain  and  leverage  the  core  expertise  appropriately. 
Management  of  the  domain  is  unified  to  achieve  a  proper  balance  between  strategic  business 
objectives  and  current  project  needs. 

•  Most  of  the  Application  Engineering  process  focuses  on  capturing  and  refining  an  understanding 
of  a  customer’s  requirements  in  an  Application  Model  and  comparing  standard  alternative 
solutions  that  satisfy  the  model.  Work  product  creation  is  reuse-based  and  largely  automated, 
as  is  support  for  much  of  the  rest  of  the  process. 

A  leveraged  Synthesis  process  is  one  in  which  strategic  business  needs,  tempered  by  past  project 
experience  and  current  project  needs,  define  a  domain  that  motivates  reuse  as  a  vehicle  for  achieving 
long-term  organizational  objectives.  A  separate  application  engineering  project  is  instituted  to  serve 
each  customer  having  a  problem  judged  to  be  within  the  domain. 

In  a  leveraged  Synthesis  process,  projects  follow  a  standardized,  reuse-driven  process  (e.g.,  like  the 
one  shown  in  Figure  OV.2-4)  that  results  from  an  analysis  by  Domain  Engineering  of  how  projects  can 
operate  most  effectively  doing  family-oriented  reuse  (Figure  OV.2-5).  At  the  leveraged  stage  of  imple¬ 
mentation,  Domain  Management  focuses  Domain  Engineering  efforts  on  the  adaptable  standardiza¬ 
tion  of  the  process  and  products  of  Application  Engineering  to  improve  the  life-cycle  productivity  of 
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the  total  software  development  enterprise.  The  deliverable  work  products  of  each  Apfdicaticm 
Engineering  project  are  mechanically  derived  from  an  Api^cation  Model  and  ckxnain-spedfic  adi^- 
able  specifications,  designs,  and  implementations,  resulting  in  a  tailored,  int^rated  softie  product 
At  this  stage,  the  concept  of  a  reuse  library  is  subsinned  into  a  broader  framework  of  {nocess  support 
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Figure  OV.2-4.  A  IVototypical  ^^licatioa  Engbeering  IVooess  for  Leveraged  Reuse 


23.5  An  Ai^cipating  Synthesis  Process 

Your  organization  can  adopt  an  anticipating  Synthesis  process  if  it  is  targeting  a  new  state  of  jnactice 
similar  to  the  following: 

•  Managanent.  Domain  and  application  projects  are  managed  as  vehicles  to  serving  a  perceived 
customer  market.  Management's  objectives  try  to  anticipate  and  stimulate  customer  ei^iecta- 
tions  to  match  the  organization’s  capabUities  and  assets.  Application  projects  are  initiated  be¬ 
cause  of  a  recognition  that  they  fit  with  and  can  leverage  the  organization’s  expertise.  Domain 
and  application  project  resouces  are  strategically  coordinated  to  seek  optimum  value  from  the 
investment. 

•  Application  Devdopment.  The  ^plication  Product,  including  deliverable  versions  of  all  work 
products,  are  derived  entirely  from  an  ^plication  Model  leveraged  with  domain  assets.  The 
process  is  highly  iterative,  customer-involved,  and  systematic,  including  the  use  of  predictive 
models  of  system  properties  that  aid  the  engineer  in  rapidly  delivering  an  acceptable  product. 
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Any  inadequacies  that  cannot  be  remedied  effectively  throu^  the  ^)idication  Model  are 
referred  to  Domain  Engineering  for  improvement. 

Asset  Devdopmaa.  Domain  Engineering  provides  assets  and  automation  sufiBdoit  to  build  and 
deliver  comitiete  [n-oducts  that  match  the  needs  of  ^>plicati<m  Engineering  projects.  Fre> 
viously  undiscovered  needs  are  rapidly  introduced  within  a  flexible  and  ccmsistait  framewc^ 
of  existing  capabilities.  Efforts  to  identify  new  needs  and  improve  responsiveness  to  existing 
needs  stimulate  continuing  evolution  of  the  domain. 

flruemaiid  Tbdknefogy.  Both  the  Domain  Engineering  and  Api^hcation  Engineering  processes 
are  systematicalfy  adapted  to  suit  the  evolving  needs  of  the  organization  and  its  market  Eadi 


Oy2.RiadM»eamioC%1lwiii 


of  the  {M-ocesses  is  ofAiinally  automated  based  on  an  analysis  <^oost  and  benefit.  Tbe  processes 
and  suppmting  technologies  are  int^ated  for  rapid  response  to  changing  circumstances. 

At  the  anticipating  stage  of  implementation,  the  en^)hasis  is  tm  anticipating  and  aeating  a  market  for 
an  organization’s  product  line.  The  focus  of  iiwestment  is  on  predicting  future  market  needs  and  aeat> 
ing  assets  that  will  serve  those  needs.  .^)plication  projects  are  sought  that  iK>t  only  eq^t  existing  ca¬ 
pabilities  but  also  provkle  opportunities  for  enhimcing  those  c^Mbilities.  Apf^katicm  projects  are 
seen  as  a  means  to  api^  the  knowdedge  and  expertise  embodied  in  a  domain  to  problems  that  can 
benefit  from  this  knc^ledge  and  expertise. 

^>plication  Engineering  and  Domain  Engineering  processes  tyf»cal  of  an  antidpatii^  Synthesis 
practice  have  not  yet  been  defined. 
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This  pagt  intentumalfy  lefibUmk. 


OV.  OVERVIEW  OF  AN  OPPORTUNISTIC 
SYNTHESIS  PROCESS 


This  part  of  the  guidebook  (veseiits  an  opportunistic  ^thesis  process.  This  is  a  [M'ocess  suitable 
an  organization  that  has  achieved  the  goals  associated  with  the  opportunistic  stage  of  reuse  capability, 
as  defined  by  the  RCM.  lb  help  you  understand  whether  an  opportunistic  jvocess  suits  your  organiza¬ 
tion,  this  section  discusses  the  assumptions  that  underlie  Ae  process  and  the  nature  of  software 
develo(»nent  vdien  using  the  (H-ocess. 

1.  UNDERLYING  ASSUMPTIONS 

The  RCM  defines  four  stages  of  reuse  capability  implementation  and  duuracterizes  each  stage  by  a 
set  of  goals.  The  0{^rtunistic  Synthesis  jarocess  described  in  this  part  of  the  guidebook  was  designed 
to  fit  the  goals  associated  with  the  opportunistic  stage  as  described  in  the  Fundamentals  section  of  the 
overview  to  this  guidebook  (Section  OV.2).  lb  adopt  this  process,  an  organization  will  have  targeted 
those  goals  as  a  minimum,  rather  than  the  more  ambitious  goals  associated  with  other  stages.  Your 
organization  may  choose  to  adopt  the  opportunistic  process  even  if  it  has  the  potential  to  attain  goals 
associated  with  more  advanced  stages  of  reuse  capability  implementation.  However,  this  i^ocess  does 
not  depend  upon  nor  require  your  organization  to  attain  aity  of  the  more  ambitious  ^als  associated 
with  more  ad^ced  stages. 

The  goals  assodated  with  the  opportunistic  stage  introduce  requirements  for  a  process  to  be  used  by 
organizations  targeting  that  stage.  The  Synthesis  process  described  in  this  part  of  the  guidebook  is  one 
examine  of  a  process  that  an  organization  targeting  the  opportunistic  stage  could  adopt  It  differs  fi’om 
other  such  processes  because  it  reflects  assumptions  alwut  an  organization's  circumstances  that  ex¬ 
tend  those  implied  by  the  RCM  ^als  for  the  oppcvtunistic  stage.  Section  23  in  Fart  Syn  of  the  guide¬ 
book  describe  diaracteristics  common  to  all  ^thesis  processes,  particularly  that  the  process  com- 
jaises  iteratively  cooperating  Domain  Engineering  Application  Engineering  subjMrocesses. 
Additional  assumptions  that  distinguish  the  opportunistic  ^foesis  process  are  as  follows: 

•  Managers  and  eng^inears  are  worUng  in  a  familiar  domain,  ^>plication  engineers  are  building  a 
product  similar  to  one  they  have  built  before,  and  domain  engineers  are  anatyzing  products 
of  a  sort  with  which  th^  have  aq)erience.  The  "theory"  underlying  the  product  is  familiar  to 
them,  at  least  intuitively  based  on  previous  experiences,  th^  have  some  idea  of  aj^ojMnate 
design  struchires  (e.g.,  process  communication  models)  and  testing  strategies.  Also,  th^ 
know  the  types  of  work  products  that  they  will  produce  as  part  of  their  normal  ^)plication 
Engineering  routine  (requirements  documents,  design  documents,  etc.);  the  form  and  struc¬ 
ture  of  each  wwk  pnx^  (^g.,  DOD-SrD-2167A):  and  foe  process  by  which  projects  produce  work 
products. 
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In  Other  words,  domain  and  aj^lication  engineers  understand  existing  problems  and  solutions 
in  the  domain.  Generally  speaking,  domain  engineers  do  not  have  to  create  new  ways  to  de¬ 
scribe  problems  and  solutions.  They  only  need  to  document  them,  codifying  their  intuitions, 
common  sense,  and  day-to-day  practices.  They  can  assume  aj^cation  engineers  understand 
problems  similarly  and  know  how  to  make  af^opriate  use  of  existing  solutions. 

•  77lw  ofgomzofioRikisdbdb/ied  and  lusocveasmsimikirsyfliems.  In  the  near-term,  the  organization 
«^ects  to  develop  systems  similar  to  those  that  it  has  built  in  the  past  Knowledge,  experience, 
and  existing  work  products  are,  therefore,  relevant  to  current  and  {banned  systems.  Domain 
engineers  have  access  to  application  engineering  work  products  of  the  types  they  ]dan  to  make 
available  for  reuse.  These  work  products  include  code,  documentation,  test  plans,  and 
anything  else  that  might  have  reuse  value. 

This  assumption  improves  the  viability  of  a  domain,  independent  of  reuse  stage.  Domain 
engineers  can  rely  entirely  on  their  knowledge  and  experience,  but  detailed  analyses  of  pre¬ 
viously-developed  work  products  can  provide  increased  insight  and  ground  the  result  in  real¬ 
ity.  Existing  work  products  provide  raw  material  from  which  a  reuse  library  can  be  derived, 
with  more  confidence  and  less  effort  than  ori^nal  development  provides. 

•  The  rokqf  Domain  Engineerit^  is  to  increase  opporUauiies  for  reuse  durit^AppUeaiionEnpneering. 
This  assumption  has  two  meanings.  First,  domain  engineers  obtain,  codify,  and  organize  do¬ 
main  knowledge  and  existing  work  products.  Domain  engineers  focus  on  providing 
accurately-documented,  existing  work  products  to  application  engineers. 

Second,  domain  engineers  sometimes  reengineer  existing  work  products  to  satisfy  new  needs. 
Strictly  speaking,  reengineering  does  not  occur  in  a  pure  opportunistic  process,  where  domain 
engineers  only  take  advantage  of  existing  opportunities— i.e.,  existing  work  products.  The 
pure  opportunistic  process  limits  reuse  to  needs  of  past  application  engineering  projects.  This 
approach  is  undesirable  if  domain  engineers  perceive  greater  opportunity  by  satisfying  new 
needs,  they  should  provide  a  solution  to  those  needs. 

•  Application  engineers  want  to  use  a  familiar  process.  Application  engineers  are  already  familiar 
with  the  types  of  work  products  that  their  customers  require  for  the  domain,  and  with  the  pro¬ 
cess  for  producing  them.  They  want  to  use  this  process  on  the  current  project.  Application  en¬ 
gineers,  therefore,  have  expectations  about  the  types  of  work  products  they  will  produce  and 
the  order  in  which  these  work  products  are  a-eated.  Reuse  must  not  affect  either  the  form  or 
the  order.  In  other  words,  it  must  not  influence  the  overall  ^plication  Engineering  process. 

•  Reusefocu^  on  resolvir^  variations  amot^  members  ofawotli  product famify.Tbis  means  that 
sufficient  flexibility  in  reuse  depends  on  accommodating  variations.  Domain  engineers  stan¬ 
dardize  a  work  product  family  by  identifying  commonalities  and  variabilities  that  characterize 
its  members.  Commonalities  provide  the  basis  for  potential  leverage,  in  that  they  express  gen¬ 
eral  Application  Engineering  needs.  Variations  correspond  to  decisions  that  application 
engineers  need  to  make  to  express  their  needs  precisely. 

•  Domain  Engineering  supports  only  one  application  engfneeringprojectata  time.  Domain  engineers 
scope  a  domain,  and  focus  their  efforts  on  creating  reusable  products,  based  on  the  needs  of 
a  single  application  engineering  project  Domain  engineers  support  a  current  project  that  is 
similar  to  previous  projects  and  a  predictor  of  future  projects.  The  organization  expects  to 
reuse  the  resulting  assets  in  both  the  current  and  future  projects. 
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This  assumptkm  provides  domain  engineers  with  a  str(»^  focus.  Thdr  examiiiatkm  <tf  exiting 
material  ai^  the  goals  th^  set  for  reuse  are  tied  to  one  project,  not  to  an  entire  wganusation 
or  to  antidpated  [Mrojeds  (a  consideration  at  later  stages  of  reuse  capat^ty).  Also,  this  as¬ 
sumption  helps  justify  having  the  current  project  directly  fund  Domain  Engineering  wmk  in 
the  early  stages  of  reuse  {M’ogram  implementation. 

2.  SOFTWARE  DEVELOPMENT  WITH  AN  OPPORTUNISTIC  SYNTHESIS  PROCESS 

This  section  is  a  general  overview  of  the  opportunistic  Synthesis  [vocess  {x^esented  in  this  part  of  the 
guidebook.  It  gives  an  overall  feel  for  software  development  and  management  as  {xacticed  ^  an  orga¬ 
nization  with  opportunistic  reuse  capabilities,  without  elaborating  every  activity  or  every  possible  vari¬ 
ation  or  interpretation  of  the  process.  As  Figure  OV.2-1  in  Fart  S|yn  de|»cts.  Domain  En^eering  and 
Application  ^gineering  activities,  and  the  interactions  between  them,  are  defining  aspects  of  any 
Synthesis  process.  This  section  describes  this  opportunistic  Synthesis  process  from  three  perspeoives: 

•  The  (xganization  controlling  App^cation  Engineering  (appUcation  strftware  development  m 
satisfy  a  particular  customer)  and  Domain  Engineoii^  (the  effiM  invested  in  reuse)  widiin  a  domain 

•  An  individual  application  engineering  project 

•  The  domain  engineering  project  for  a  domain 

This  section  concludes  with  a  brief  scenario  of  how  Domain  Engineering  and  an  >^{dication 
Engineering  project  interact. 

2.1.  Organizational  Perspective 

In  opportunistic  reuse,  an  organization’s  strategy  is  to  leverage  reusable  assets  as  best  it  can  with 
minimal  investment.  Reuse  at  the  opportunistic  stage  is  not  a  key  business-area  strategy  but  rather 
an  opportunity  exploited  on  a  project-by-project  basis.  The  business  organization  may  allocate  limited 
initial  funding,  but  in  general  wodd  like  to  operate  in  a  "pay-as-you-go”  mode:  each  increment  of  in¬ 
vestment  in  reuse,  whether  from  organization  or  project  funds,  should  result  in  a  payoff  for  a  spedfic 
project  (against  which  direct  costs  are  charged  and  justified). 

This  business/management  orientation  motivates  how  Synthesis  is  interpreted  for  the  opportunistic 
context.  As  always  with  Synthesis,  Domain  Engineering  «dsts  to  support  ^plication  E^neering. 
However,  in  the  opportunistic  process.  Domain  Engineering  focuses  on  current  needs.  The  current 
needs  are  defined  ^  the  application  engineering  project  targeted  for  support  by  Domain  Engineering. 
However,  the  organization  can  expect  Domain  Engineering  products  to  be  useful  on  other  application 
engineering  projects  that  are  building  applications  in  the  same  domain. 

The  first  time  an  organization  practices  Synthesis,  it  may  have  to  expend  preliminary  effort,  beyond 
current  project  needs,  to  get  up  to  speed.  Once  a  domain  exists,  there  are  reusable  assets  that  future 
projects  can  use  as  well.  Each  time  an  organization  begins  a  new  project,  it  considers  focusing  Domain 
Engineering  on  that  project.  The  domain  engineering  project  revises  costing  domain  work  products 
to  reflect  any  differing  needs  of  this  new  application  engmeering  project.  As  the  project  proceeds.  Do¬ 
main  Engineering  adds  and  revises  reusable  assets  to  correspond  to  the  current  concept  of  the 
commonalities  and  variabilities  among  systems  in  the  domain  and  their  associated  work  products. 
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2.2.  Appucahon  Engineering  Perspective 

At  the  opportunistic  stage  of  reuse  program  implementation,  the  current  project  shares  a  framework 
of  process  and  work  products  with  past  projects.  This  framework  links  the  reuse  program’s  success  to 
the  individual  application  engineer’s  ability  to  take  advantage  of  reuse  opportunities  as  he  builds  eadi 
work  product. 

Apjdication  Engineering  follows  its  (Hganizadon’s  n(»mal  process,  probably  similar  to  the  waterfrdl-like 
process  depicted  in  Figure  OV-l.  However,  whenever  Domain  Engineering  has  provided  reusable  as¬ 
sets  associated  with  a  particular  type  of  work  product,  the  aj^lication  engineer  has  the  ability  (and 
responsibility)  to  evaluate  and  exploit  opportunities  for  reuse  in  creating  that  work  product.  Such  re¬ 
use  can  leverage  existing  work  products  of  the  same  type,  either  in  their  structure,  in  the  content  of 
portions,  or  in  their  entirety.  In  any  case,  the  application  engineer  will  likely  have  to  tailor  the  resulting 
draft  work  product  for  it  to  meet  f^y  the  predse  needs  of  the  current  project.  Whenever  the  engineer 
is  imable  to  create  the  entire  work  product  through  reuse,  he  still  has  the  ability  to  work  conventionally 
to  create  the  appropriate  final  work  product. 

2J.  Domain  Engineering  Perspective 

In  o[^rtunistic  reuse,  the  goal  of  Domain  Engineering  is  to  suf^rt  reuse  an  api^cation  engineering 
project  in  a  way  that  minimizes  an  application  engineer’s  effort  to  discover  whether  reuse  is  feasible. 
Domain  Engineering  adopts  a  narrow  focus  on  each  work  product  that  application  engineers  have  to 
create.  %  analyzing  the  commonalities  and  variabilities  of  a  work  product  type  that  has  been  pro¬ 
duced  by  previous  projects,  domain  engineers  can  focus  the  attention  of  the  ^plication  Engineering 
to  those  work  products  and  aspects  of  each  that  are  most  likely  to  yield  effective  reuse. 

Tb  have  sufficient  context.  Domain  Engineering  works  on  supporting  reuse  for  a  work  product  just 
prior  to  the  planned  Application  Engineering  activity  for  producing  it  Domain  Engineering  uses  work 
products  and  other  information  from  preceding  phases  of  ^plication  Engineering  to  determine 
which  reusable  assets  are  most  likely  to  fulfill  the  needs  of  the  next  phase.  Ideally,  the  past  is  a  perfect 
predictor  of  the  future,  and  assets  of  past  projects  fit  perfecdy  wiffi  the  current  project.  In  practice, 
application  engineers  will  need  assistance  in  making  the  correct  match  and  adjustments  between  need 
and  available  reusable  assets. 

Where  the  predicted  neevls  for  the  current  project  only  partly  match  existing  domain  assets,  domain 
management  must  decide  whether  original  work  is  justified.  When  the  current  project  has  a  need  that 
is  different  from  previous  projects,  the  need  may  be  unique  to  that  project  or  it  may  indicate  an  impor¬ 
tant  new  need  of  all  future  projects.  As  a  rule,  until  a  need  can  be  clearly  characterized  as  a  common 
need,  it  remains  outside  the  scope  of  further  Domain  Engineering  consideration.  In  opportunistic  re¬ 
use,  there  must  be  an  expectation  of  future  recurring  uses  to  justify  a  reuse-oriented  investment  Ap¬ 
plication  engineers  must  handle  whatever  custom  development  is  necessary  to  address  any  needs  per¬ 
ceived  as  unique  to  their  project  However,  when  a  similar  need  arises  for  a  subsequent  project,  there 
is  then  a  foundation  of  «dsting  application  work  products  from  which  Domain  Engineering  can  (reate 
reusable  assets  and  enhance  the  domain. 

Even  when  common  needs  dearly  odst  Domain  &igineering  is  not  obligated  to  provide  reusable 
assets  for  every  work  product  of  Application  Engineering.  The  domain’s  resources  must  be  intelligent¬ 
ly  allocated  to  work  products  that  offer  the  most  potential  benefit  from  reuse.  Domain  engineers  work 
with  particular  work  products  based  on  the  following  criteria: 
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Product  Verification 
and  \%didation 
-  ' 

Operation  and 
Maintenance 


^  Rgure  OV-2  depicts  a  blowup  of 
the  activities  inside  this  Family 
Development  box. 


to  Customer 


Figure  OV-1.  Example  ^jplication  Engineering  and  Dmnain  Engineering  Interactim 
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to  Application  Engfneerit^ 


HgureOV-2.  Blowup  a  Work  IVoductRmiljrDevelopmeDt  Activity  Group 

•  Domain  Engmeering  can  extract  the  needed  work  products  from  previous  applications 
(perhaps  with  some  modification  to  put  them  into  a  more  reusable  form). 

•  Domain  Engineering  can  provide  the  needed  work  products  within  the  project’s  schedule  for 
this  work. 

•  The  cost  to  recover  and  reuse  an  asset  will,  at  most,  equal  the  cost  for  addressing  the  need  via 
custom  development. 

Hgure  OV-3  shows  the  relationship  between  this  M^rk  product  development  approach  (Figures  OV-l 
and  OV-2)  and  Domain  Engineering  as  discussed  in  remainder  of  this  guidebook. 


2.4.  An  Example  Scenario 

Consider  the  hypothetical  process  in  Figure  OV-l.  Domain  Engineering  supports  the  reuse  of  three 
types  of  work  products:  requirements  documents,  design  documents,  and  computer  software  units. 
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2  The  Product  Implementation  and  ftooea  Support 
activities(ahowninRgureOV-2)arepartoftheDoiiiam 
Implementatko  Activity. 

^  The  IVoject  Support  Activity  as  shown  here  represents 
the  combinatioa  of  all  work  product  Roject  Support 
activities  dejncted  in  Hgure  OV-2. 

IngureOV-3.  Rdatkmship  Between  Wcrk  Product  FunityDevelopaient  and  Domain  Engineering 


Application  Engineering  begins  with  software  ^tems  engineering,  establishing  the  system 
requirements  and  ^tem  design.  During  software  ^tems  engineering,  Domain  Engineering  creates 
a  Domain  Definition,  a  general  desorption  of  the  domain  scope,  and  Process  Requirements,  a  de- 
SCTiption  of  the  expected  process  and  work  products  of  ^>plication  Engineering.  The  Domain  Defini¬ 
tion  identifies  existing  ^tems  that  are  in  the  domain  and  available  to  Domain  Engineering  as  source 
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of  raw  material.  Normally,  a  new  project  continues  a  line  of  business  that  the  organization  has  been 
pursuing;  this  presumption  is  the  basis  for  intuitive  expectations  for  reuse  opportunities. 

As  the  project  progresses  through  the  ^plication  Engineering  process  producing  work  products,  the 
application  engineers  look  for  opportunities  to  reuse  existing  work  i»r(^ucts,  in  whole  or  in  part  In 
order  to  make  reuse  attempts  for  particular  work  products  more  effective.  Domain  Engineering  at¬ 
tempts  to  organize,  improve,  combine,  and  document  existing  work  products  of  that  type.  In  this  exam¬ 
ple,  Domain  Engineering  has  determined  that  software  requirements  documents,  software  design 
documents,  and  software  components  offer  the  best  opportunities  for  reuse  by  the  current  project.  As 
a  result,  domain  engineers  focus  their  efforts  on  enhancing  the  reusability  of  those  work  jn'oducts  and 
helping  application  engineers  recognize  and  exploit  them  as  opportunities  arise. 

implication  Engineering  benefits  firom  opportunistic  ^thesis  because  Domain  Engineeiing  identifies 
and  provides  potentially  reusable  existing  assets  based  on  perceived  needs  of  the  current  project.  This 
focus  makes  the  likelihood  of  reuse  greater  than  if  Domain  Engineering  populated  the  library  with 
arbitrary  components.  Because  the  organization  expects  more  business  in  the  domain,  it  anticipates 
that  this  effort  will  benefit  future  projects  as  well. 
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1.  GETTING  STARTED 

Domain  Engineering  is  an  activity  of  a  Synthesis  process  that  creates  and  supports  work  {voducts 
\diidi  support  the  i^lication  En^eering  process  in  a  business  area,  particularly  with  respect  to  the 
needs  of  a  specific  project  (hereafter  termed  the  targeted  project).  Domain  Engineering  is  a  compre¬ 
hensive  iterative  life-c^e  process  with  management,  analysis,  implementation,  and  support  activities 
for  a  product  family.  A  product  family  is  represented  by  a  collection  of  work  product  families. 

1.1  Objectives 

The  objectives  of  Domain  Engineering  are  to: 

•  Organize  and  direct  resources  to  facilitate  opportunities  for  reuse  of  existing  application 
engineering  work  products  by  the  targeted  project  within  an  organization 

•  Define  the  nature,  extent,  and  substance  of  a  set  of  work  {voduct  families  that  complements  those 
opportunities  for  reuse 

1.2  Required  Information 

Domain  Engineering  requires  the  following  information: 

•  Domain  knowledge  (including  existing  products) 

•  Business  objectives 

13  Required  Knowledge  AND  Experience 

Domain  Engineering  requires  domain  and  software  knowledge  and  experience  in: 

•  The  needs  that  motivate  systems  in  the  domain  (i.e.,  application  engineering  work  products) 
and  associated  work  products 

•  The  environments  in  which  the  systems  in  the  domain  will  operate 

•  How  the  systems  in  the  domain  are  built 

•  How  application  engineering  projects  in  the  domain  are  managed 
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2.  PRODUCT  DESCRIPTION 

Domain  Engineering  creates  four  work  {voducts:  Domain  Plan,  Domain  Definition,  Domain 
Specification,  and  Domain  Implementation.  Domain  engineers  evolve  these  products  in  subsequent 
iterations  of  Domain  Engineering  to  support  future  projects,  consistent  with  organizational  business 
objectives. 

2.1  Domain  Plan 

Purpose  A  Domain  Plan  (see  Section  DE.1)  establishes  the  scope  of  domain 

development  and  defines  the  tasks  and  resource  allocations  for  domain 
development  increments. 

Utifiaoion  The  expected  needs  of  plaimed  projects  in  the  business  area  are  sufficient  to 

Criteria  compensate  for  projected  costs  and  risks  of  domain  development. 

2.2  Domain  Definhion 

A  Domain  Definition  (see  Section  DE.2.1)  defines  the  informal  scope  and 
orientation  that  characterize  a  viable  domain. 

The  Domain  Definition  captures  sufficient  information  to  allow  domain 
engineers  to  describe  any  existing  or  potential  system  in  the  domain  (in 
particular,  the  system  being  built  by  the  targeted  project). 

23  Domain  SPEcmcAnoN 

A  Domain  Spedfication  (see  Section  DE3.2)  defines  a  set  of  work  product 
families  that  provides  increased  opportunities  for  reuse  to  the  targeted  project 
within  its  Application  Engineering  process. 

The  Domain  Specification  predsely  expresses  the  domain  as  captured  in  the 
Domain  Definition. 

2.4  Domain  Implementation 

Purpose  A  Domain  Implementation  (see  Section  DE3)  is  an  implementation  (with 

documentation  and  automata  support)  of  a  set  of  work  product  families,  as 
prescribed  by  the  Domain  Spedfication. 

Ver^icarion  The  Domain  Implementation  provides  eadi  work  product  family  desoibed  in 

Criteria  the  Domain  Spedfication. 

3.  PROCESS  DESCRIPTION 

Domain  Engineering  is  an  interaction  among  the  four  steps  shown  in  Figure  DE-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Engineering  Activity. 


Purpose 


Vaificarion 

Criteria 


Purpose 

Verification 

Criteria 


0(^10 


toAppBcationEngUtMring 

Figure  DE-1.  Domui  Eogmeering 


Step:  Domain  Management  Activity 

Action  Plan,  monitor,  and  control  the  use  of  domain  resources  to  provide  reusable 

work  product  families  for  a  domain  of  interest  to  ivojects  within  a 
business-area  organization. 

Result  Domain  Han 

Hatristies  Define  near-term  objectives  that  suf^rt  the  application  engineering  jvoject 

targeted  1^  Domain  Engineering.  Organize  and  manage  donuun  resources  to 
adiieve  th^  objectives. 

Step:  Domain  Analysis  Activity 

Action  Scope  and  spedfy  a  domain  based  on  an  analysis  of  needs  of  a  targeted  project 

in  an  organization. 
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bpid  Domain  Plan 

Amir  •  Dcmiain  Definition 

•  Domain  Spedficatkm 

Heuristics  •  Create  an  informal  definitkm  the  domain.  Characterize  its  scope,  the 

adjects  ornunon  to  all  ^tems  in  the  domain,  and  the  features  thin  vary 
across  systems  in  the  domain.  Also  dtaracterize  the  wcvk  products  com¬ 
monly  produced  as  part  of  Applicatimi  Engineerii^  Eiq^tly  state  n^t 
is  not  part  of  the  domain.  Pro^^  a  glossary  common  terms.  Assess  the 
viability  of  supporting  each  of  the  aspects  ymi  have  characterized. 

•  Precisely  specify  problems  within  the  scope  of  the  domain.  Describe  bodi 
common  problems  and  variatimis  in  those  problems.  Specify  solutions  to 
the  problems  in  the  domain  so  that  the  solutions  vary  in  the  same  way  as 
the  proUems.  Identify  important  work  products  (i.e.,  those  susceptible  to 
reuse).  Specify  the  Aj^cation  Engineering  process  conunonly  us^  inthe 
domain,  showing  when  a  given  work  (voduct  is  developed.  Determine  the 
work  products  for  nhidi  (reusable)  work  product  fomilies  will  be 
developed. 

Step:  Domain  Implementation  Activity 

Action  Implement  the  domain  as  defined  the  Domain  Specification. 

Input  •  Domain  Definition 

•  Domain  Spedfication 

•  Domain  Plan 

Result  Domain  Implementation 

Heuristics  •  Imfdement  the  work  {X'oduct  families  and  process  described  in  the  Domain 

Specification.  Incorporate  variations  into  the  imjdementation  of  the 
solutions.  Structure  the  implementation  of  the  solutions  as  a  set  of  work 
product  families,  each  of  whidi  supports  reuse  for  a  particular  work 
product  that  api^cation  engineers  mi^t  want  to  develop. 

•  Desalbe  conventions,  procedures,  and  standards  for  using  these  work 
products.  Document  how  application  engineers  can  perform  reuse  based 
on  these  descriptions.  If  time  and  resources  permit,  automate  routine 
time-consuming  tasks. 

Step:  Project  Support  Activity 

Action  Support  a  project  in  performing  the  ^^lication  Engineering  {vot^ss. 

In^  Domain  Implementation 
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OmmitikM  Deliver,  imtall,  and  support  the  Dooudm  In^ilaneittaiion  for  use  by  the 

targeted  project 

Risk  Managemekt 

The  product  of  Domain  Engineering  will  ncrt  lead  to  standvdized  domain 
reuse  practices  on  projectt 

The  Domain  Engineering  investment  will  not  produce  projected  benefits  for 
the  targeted  project  or  the  Inisiness  (vganizatkm. 

•  Staff  the  Domain  Engineeriog  wwk  with  e3q)erimioed  project  managers 
and  engineers.  Ensure  that  aU  work  is  actively  reviewed  by  other  e3q)eri- 
enced  managers  and  engineers  and  is  adequately  reviewed  by  all  partici¬ 
pants  of  apfdication  ei^ineering  projects.  Indude  ei^eers  familiar  with 
the  needs  (k  the  targeted  project 

•  Evaluate  the  effectiveness  of  the  Domain  Engineering  process  and  work 
products  rdathre  to  past  project  experiences.  Ensure  that  the  characteris¬ 
tics  of  that  experience  or  the  resulting  ^tems  are  not  in  conflict  with  the 
(vocess  and  work  products. 

4.  INTERACTIONS  \¥ITH  OTHER  ACTIVITIES 

4.1  Feisback  TO  IfntoMtourioN  Sources 
None 

4.2  Feedback  From  Product  Consumers 

Conlingenq^  The  work  product  families  are  inadequate  to  su|^rt  the  needs  of  the  targeted 

{M'oject. 

Source  Application  Engineering 

Response  •  Determine  that  exfvessed  needs  are  outside  of  tv  otherwise  conflict  with 

chosen  domain  objectives  or  cannot  be  viably  satisfied  given  available 
domain  resources. 

•  Evolve  the  domain  to  satisfy  current  needs. 


Risk 

tmpBeaRim 

hOtitation 


Opp-13 


OB.  Dcnia  EiiiMitrit  Oiwwhwr 


This  page  intentumalfy  left  bUmk. 


Opp-M 


DE.1.  DOMAIN  MANAGEMENT  ACnVITY 


1.  GETTING  STARTED 

Domain  Management  is  an  acdviQr  of  Domain  Engineering  for  managing  business-area  resources  to 
increase  opportunities  for  cost-effective  reuse  of  {deviously  developed  assets.  Domain  Management 
l^ans,  assigns  resources,  and  directs  Domain  Engineering  to  serve  the  needs  oi  a  targeted  applicatitm 
engineering  project. 

Domain  Engineering  develops  and  evolves  a  domain  through  a  series  of  increments.  The  Domain  Flan 
lays  out  both  a  master  plan  for  evolution  throi^  [vojected  increments  (evcdudon  [dan)  and,  as  each 
increment  is  initiated,  a  detailed  plan  for  each  inaement  (inaement  ]dan).  The  evolution  plan  identi¬ 
fies  the  systems  that  provide  the  basis  for  a  domain  (i.e.,  the  source  of  raw  material)  aiul  the  applica¬ 
tion  engineering  projects  that  are  targeted  for  support.  An  increment  plan  determines  how  domain 
engineering  resources  are  af^lied  to  aeate  reusable  assets  that  can  exploited  effectively  in  the 
targeted  application  engineering  project. 

Domain  Management  monitors  domain  engineerii^  performance  to  assess  progress,  ensure  proper 
adherence  to  plans,  and  guide  needed  revisions  to  the  evolution  and  increment  jdans  based  on  feed¬ 
back  from  implication  Engineering  use  of  domain  assets.  A  key  concern  of  Domain  Management  is 
coordinating  Domain  Engineering  activities  to  support  the  ne^  and  priorities  of  targeted  applica¬ 
tion  engineering  projects  in  satisfying  customers’  needs.  Domain  Management  attempts  to  ensure  ef¬ 
fective  use  of  allocated  resources  by  coordinating  its  planning  to  match  the  needs  of  a  targeted 
apfdication  engineering  project. 

1.1  Objectives 

The  objective  of  Domain  Management  is  to  manage  business-area  resources  to  create  cost-effective 
reuse  opportunities  for  a  targeted  application  engineering  projea.  Management  establishes  dmnain 
objectives  for  the  organization  to  guide  the  (reation  and  revision  of  an  increment  {dan  for  a  series  of 
domain  increments.  An  ino-ement  begins  when  a  (voject  is  first  targeted  for  support  or  Mien  the  needs 
or  status  of  the  targeted  project  changes  significantly. 

For  each  increment  of  development.  Domain  Management  develops  a  jidan  to  deliver  capabilities  that 
match  the  needs  of  targeted  application  engineering  projects.  A|^lication  engineering  projects  are 
planned  independently,  but  with  an  awareness  of  domain  capabilities,  to  meet  particular  customer 
needs. 


1.2  Required  Information 

The  Domain  Management  Activity  requires  the  following  information: 
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•  Business  objectives,  specifically  the  priorities  of  executive  management  for  business  area 
development 

•  Domain  Definition;  Domain  Status 

13  RsQunEDKmwLEDGE  AND  Experience 

The  Domain  Management  Activity  requires  domain  and  business-area  Imosdedge  and  experience  in: 

•  The  nature  of  projects  in  the  business  area 

•  All  aspects  of  strategic  business-area  management  in  the  organization, 

•  All  aspects  of  ao>lication  project  management  in  the  organization 

2.  PRODUCT  DESCRIPTION 

Name  Domain  Plan 

Purpox  Define  near-term  objectives  for  a  business  area  and  organize  and  manage 

domain  resources  to  adiieve  those  objectives. 

Content  A  Domain  Plan  consists  of  three  parts: 

•  Domain  Evolution  Plan.  The  Domain  Evolution  Plan  establishes  a 
purpose  and  scope  for  near-term  domain  development. 

•  Practices  and  Procedures.  Practices  and  Procedures  presaibe  the 
preferred  practices  and  procedures  that  are  to  guide  the  proper 
performance  of  domain  development. 

•  Domain  Increment  Plans.  A  Domain  Increment  Plan  spedfies  how  to 
organize  and  manage  Domain  Engineering  resources  to  facilitate  re¬ 
use  of  previously  developed  assets  by  the  targeted  application 
engineering  project 

Both  the  DomainEvolution  Plan  and  the  Domain  Increment  I^ans  indude  the 
following; 

•  Identification  of  uncertainties  in  meeting  allocated  Imtiness 
(for  the  Domain  Evolution  Han)  or  domain  (for  a  Domain  Incranmt 
Plan)  objectives,  assessment  of  the  risks  of  failure,  and  identification  of 
mitigation  strategies. 

•  Objectives.  The  scope  and  focus  of  support  to  be  provided  for  the 
domain  or  the  increment  of  domain  development  reflecting  the  needs 
and  priorities  of  targeted  aj^cation  engineering  jvojects.  Scope  is  in¬ 
dicated  by  an  identification  of  previous^  built  systems  upon  vhidi  the 
domain  will  be  based;  focus  is  indicated  by  the  choice  of  targeted 
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project  Objecthvs  are  divkled  into  risk  objecth^  and  prochict  objec¬ 
tives.  Ririt  objectives  attenqx  to  mitigate  rirics  identified  in  the  risk 
analysis.  Product  objectives  establish  goals  and  success  criteria  for 
creating  specific  vvork  products. 

•  ScAadUe:  The  allocaticmofdomain  resources  to  devdc^nieotincranents 
that  satisfy  dcMnain  objectives  or  to  activities  within  an  incronent  dut  sat¬ 
isfy  inaement  objectives.  The  sdiedule  establishes  specific  milestones 
and  success  criteria  for  domain  develojunent  increments  or  for  the 
activities  of  a  development  increment. 

•  Issues.  A  description  of  issues  that  arise  in  performing  the  fdan. 

Ftmn  and  Tb  the  extent  possible,  the  form  of  a  Domain  EvoludcHi  Han  should  be  the 

Stnuture  form  your  organization  currently  uses:  the  Domain  Evolution  Han  should 

follow  the  form  used  for  business  planning;  Practices  and  Procedures  should 
follow  the  form  used  for  standardizing  the  practices  of  aj^cation  projects; 
and  the  Domain  Increment  Plans  shoulc'  follow  the  form  u^  for  allocation 
I^oject  planning. 

i^r^ication  The  verification  aiteria  for  the  Domain  Evolution  Han  are: 

Criteria 

•  The  expected  needs  (i.e.,  opportunities  for  reuse)  of  {banned  jM-ojects  in 
the  business  area  are  sufficient  to  compensate  for  projected  costs  of 
domain  development. 

•  The  Domain  Evolution  Plan  gives  the  domain  a  viable  near-term  purpose 
that  is  consistent  with  the  needs  of  targeted  projects. 

•  Each  Domain  Increment  Plan  institutes  a  plan  that  seems  likely  to  satisfy 
the  expected  needs  of  the  targeted  project. 

3.  PROCESS  DESCRIPTION 

The  Domain  Management  Activity  consists  of  three  steps  as  shown  in  Figure  DE.1-1. 

The  Domain  Evolution  step  begins  upon  creation  of  a  domain  and  continues  imtil  the  domain  is  no 
longer  judged  to  be  viable  in  serving  the  needs  of  an  application  project  within  the  business  area.  Hie 
Domain  Evolution  Plan  prescribes  a  series  of  Domain  Development  increments.  Each  inaement  is 
planned  and  performed  iteratively  until  its  objectives  in  the  Domain  Evolution  Plan  are  met.  The  Do¬ 
main  Evolution  Plan  is  subject  to  revision  after  the  completion  of  each  increment  to  reflect  progress 
or  changing  needs  of  targeted  application  engineering  projects  and  their  customers.  The  step  to  Insti¬ 
tute  Practices  and  Procedures  occurs  before  the  initiation  of  the  first  increment  of  Domain  Develop¬ 
ment  and  is  revisited  as  needed  to  update  the  Practices  and  Procedures  to  ensure  an  effective  and 
effident  ap[M‘oaui  to  Domain  ^igineering. 

The  plan  is  iterated  whenever  a  targeted  project  is  initiated,  terminated,  or  has  a  significant  change 
in  its  own  plan.  Plan  iteration  requires  you  to  reconsider  the  scope  and  focus  of  support  you  are 
providing  to  projects. 
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Domain  Anafysis,  Domain  ImpUmentadon,  andPrcjtctSui^)ort 


RgureDE.!*!.  Domain  Management  ftooess 


3.1  Procedure 

Follow  these  steps  for  the  Domain  Management  Activity. 

Step:  Domain  Evolution 

Action  Create  a  plan  for  Domain  Evolution. 

Input  •  Business  objectives 

•  Domain  Definition:  £>omain  Status 

PteaM  Domain  Plan:  Domain  Evolution  Plan 

Eeuris6c5  •  Develop  a  prioritized  set  of  near>term  domain  objectives  that  will  guide 

you  in  domain  development.  Develop  a  preliminary  statement  of  domain 
objectives  that  identifies  targeted  projects  and  their  needs.  Refine  the  ob¬ 
jectives  to  reflect  the  views  of  project  managers,  particularly  their  percep¬ 
tions  of  their  projects'  risks  and  assets  of  greatest  benefit  to  their  projects. 
(Refer  to  the  heuristics  for  the  Domain  Development  step  for  suggestions 
on  a  risk-based  management  process  that  you  can  also  apply  in  performing 
this  step.) 

•  Identify  any  previously  built  ^tems  that  are  to  be  taken  as  characteristic 
instances  of  the  domain  and  from  which  reusable  assets  are  likely  to  be 
extracted. 
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•  T\j  stating  objectives  in  terms  oi  commonalities  and  variatkms  diat 
characterize  ^ems  in  the  domain  or  thiu  arise  in  the  practice  of  Applicatioa 
Engineering. 

Step:  Institute  Practices  and  Procedures 

Action  Develop  and  document  standard  practices  and  procedures  to  be  followed  in 

the  activities  of  Domain  En^eering. 

Ii^ut  None 

Result  Domain  Plan:  Practices  and  Procedures 

Heuristics  •  Fresaibed  practices  and  procedures  should  encompass  administrative, 

software  development  (e.g.,  requirements  and  design  methods,  coding  and 
documentation  standards),  project  management  and  control,  and  quality 
assurance  (e.g.,  testing,  walkthrough,  and  review  procedures). 

•  Conflguration  management  procedures  are  a  key  element  for  controlling 
iterative  domain  development.  Each  iteration  of  domain  development  is 
represented  by  one  version  of  each  domain  engineering  work  product  that 
you  produce.  Feedback  on  the  use  of  a  product  version  leads  to  the 
creation  of  a  new  version  in  a  later  iteration  of  development. 

•  Consider  how  consisten^r  and  quality  standards  will  be  achieved  in 
domain  practices. 

Step:  Domain  Development 

Action  Create  a  plan  for  developing  a  domain  increment. 

/qpitf  •  Domain  Evolution  Plan 

•  Practices  and  Procedures 

•  Domain  Definition:  Domain  Status 

Result  Domain  Increment  Plan 

Heuristics  •  A  Domain  Development  increment  consists  of  repeated  cycles  through  a 

process  comprised  of  four  steps  as  shown  in  Figure  DE.1-2.  This  guidance 
assumes  you  are  experienced  in  project  management.  Refer  to  the  desa-ip- 
tions  of  the  process  model  and  activities  for  the  ESP  (Software  Productiv¬ 
ity  Consortium  1992b)  for  a  detailed  project  management  method  thatyou 
can  follow  to  tailor  and  elaborate  this  process. 

•  The  Domain  Evolution  Plan  identifies  the  objectives  to  be  met  by  the 
inaement.  Identify  and  rank  the  domain  development  risks  faced  by  the 
organization  in  meeting  these  objectives. 


Figure  DE.1-2.  A  Risk-Based  IVocess  for  Increment  Management 

-  A  recurring  class  of  risks  that  domain  development  must  face  is  the 
near-term  abili^  of  targeted  application  engineering  projects  to 
aeate  required  products.  Actions  to  mitigate  these  risks  take 
priority  over  other  domain  objectives. 

-  Another  important  class  of  risks  relates  to  problems  discovered  in 
previous  iterations  of  domain  development. 

•  Develop  a  prioritized  set  of  near-term  increment  objectives  that  address 
the  risks  identified  in  the  risk  analysis.  These  objectives  maybe  revised,  as 
Domain  Engineering  iterates,  to  meet  the  Domain  Evolution  Plan 
objectives  for  the  increment. 

-  A  domain-development  approach  must  address  the  short-term 
needs  of  targeted  projects. 

-  Each  objective  should  have  associated  success  criteria  that  are 
used  to  determine  whether  the  objective  has  been  met.  The  success 
criteria  should  be  written  in  such  a  way  that  they  are  directly 
measurable  (if  possible). 

-  Objectives  are  often  stated  in  terms  of  variations  that  diaracterize 
systems  in  the  domain  as  represented  by  a  set  of  work  products  or 
variations  to  be  allowed  in  the  practice  of  Application 
Engineering. 
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-  Set  objectives  for  this  increment  at  domain  developmmit  titat 
respond  to  both  the  risk  and  the  intended  result  of  donuin  objeo 
tives.  Inaement  objectives  should  a<klress  the  particular  needs  (tf 
targeted  projects. 

•  Develop  a  schedule  that  allocates  resources  to  tasks. 

-  Create  specific  goals  and  com{detion  oiteria  for  eadi  task.  Each 
task  is  characterized  by  a  Domain  Engineering  activity  to  be  per¬ 
formed  and  completion  criteria  appropriate  to  that  activity.  The 
full  set  of  tasks  must  address  the  near-term  objectives  within  the 
resource  budget  provided.  If  the  resource  budget  does  not  allow  all 
the  objectives  to  be  addressed,  the  objectives  with  the  highest 
prioriQr  should  be  addressed. 

-  Plan  for  short  iterations  so  that  mistakes  made  in  front-end  tasks 
may  be  caught  and  corrected  quickly  in  a  subsequent  iteration.  It¬ 
erations  at  the  b^inning  of  the  life  c^e  of  a  domain  should  be  par¬ 
ticularly  short  (three  to  four  months)  to  compensate  for  the  likely 
learning  curve  in  domain  concepts. 

•  Monitor  domain  engineering  work  progress  to  planned  milestones  and 
completion  criteria. 

-  The  schedule  establishes  milestones  and  completion  criteria  for 
activities  that  are  used  to  evaluate  progress.  Whenever  new  issues 
are  identified  or  progress  differs  from  that  planned,  evaluate 
whether  to  document  your  concerns  for  future  planning  or  to 
revise  the  current  plan  for  immediate  action. 

—  Document  the  source,  implications,  and  possible  and  actual 
resolutions  of  each  issue. 


3.2  Risk  Management 


Risk 

Implication 

A&^ation 


Ritic 

Implication 


Domain  plans  will  not  be  met  within  schedule  with  allocated  resources. 

Domain  capabilities  will  fall  short  of  plans. 

•  Review  plans  with  experienced  engineers  to  ensure  that  plaimed 
development  is  technically  viable. 

•  Reevaluate  domain  objectives  to  provide  for  shorter  iterations  that 
achieve  essential  capabilities  sooner;  defer  work  on  less  important 
objectives. 

Domain  engineers  resist  using  standardized  practices  and  procedures. 

Inefficient  operation  and  employee  dissatisfaction  will  reduce  productivity. 
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DB.1.  Doraaia  Manayment  Activity 


hOdgatkm 


ISdt 

Implication 


Mitigation 


Risk 

Implication 

Actuation 


Risk 

Imptication 

Mutation 


•  Involve  domain  engineers  in  developing  practices  and  procedures. 

•  Provide  education  and  apprenticeships. 

•  Conduct  pilot  projects  that  emphasize  learning  new  skills  over  product 
delivery. 

Domain  engineers  fail  to  recognize  wiien  to  terminate  an  iteration. 

•  There  will  be  excessive  detail  in  products  without  adequate  foundation  or 
potential  benefit. 

•  Schedules  will  slip. 

Review  objectives  and  completion  criteria  to  make  sure  they  are  specific  and 

understood  by  the  domain  engineers. 

Project  needs  will  not  be  met  by  plaimed  development. 

Provided  reusable  assets  will  not  have  sufficient  value  to  targeted  projects  to 

justify  costs  of  the  domain. 

Review  objectives  and  plans  with  project  managers  to  ensure  that  the  needs  of 

their  projects  and  the  projects’  customers  are  properly  understood. 

Domain  plans  will  not  be  met  within  schedule  with  allocated  resources. 

Domain  capabilities  will  fall  short  of  plans. 

•  Review  plans  with  experienced  engineers  to  ensure  that  planned 
development  is  technioilly  viable. 

•  Reevaluate  objectives  and  project  needs  to  focus  support  on  key  needs  of 
the  targeted  project  first;  defer  work  on  less  urgent  objectives. 

•  Revise  the  Domain  Increment  Plan  to  add  or  defer  activities,  or  to 
reallocate  time  and  resources  among  planned  activities,  as  priorities 
dictate. 


4.  INTERACnONSMTH  OTHER  ACnvmES 


4.1  Feedback  TO  iNFORMAnoN  Sources 

Contit^ency  The  Domain  Definition  and/or  Domain  Specification  fails  to  provide  the 

needed  capabilities  required  by  the  Domain  Plan. 

Source  Domain  Analysis  Activify 

Response  Describe  ways  in  which  the  Domain  Definition  and/or  Domain  Spedfication 

fail  to  provide  the  necessary  capabilities.  Modify  schedule  to  allow  completion 
of  indicated  Domain  Definition  or  Domain  Specification  revisions. 


Opp-22 


42  FlEBiNMCxFimMPRCNDUcrCcmsin^^ 


QmtSutfKQ 

Soiave 

Reqmnse 

Contingency 

Source 

Response 

Contingency 

Source 

Reqtonse 


Project  neetb  are  not  being  met  by  the  domain. 

Project  Support  Activity 

•  Revise  the  Domain  Plan  to  accommodate  new  needs. 

•  Determine  that  the  needs  of  a  project  are  outside  the  proper  boundaries 
of  the  domain. 

Practices  and  procedures  are  either  ineffective  or  inefficient. 

•  Domain  Anafysis  Activity 

•  Domain  Implementation  Activity 

•  Project  Support  Activity 

Revise  practices  and  procedures  to  reflect  domain  experience. 

The  Domain  Plan  is  too  ambitious  for  available  resources  or  expertise. 

•  Domain  Analysis  Activity 

•  Domain  Implementation  Activity 

•  Allocate  additional  resources  or  time  to  domain  development. 

•  Refine  the  Domain  Plan  to  reduce  the  scope. 
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DB.I.  PooMiia  IlMnyiMt  AeM/Cj 


This  page  intentionalfy  blank. 
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DE^.  DOMAIN  ANALYSIS  ACTIVITY 


1.  GETTING  STARTED 

Domain  Analysis  is  an  activity  of  Domain  Engineering  for  studying  and  formalizing  a  business  area 
as  a  domain.  The  purpose  of  formalizing  a  domain  is  to  leverage  knoudedge  of  how  recurring  and  vary¬ 
ing  problems  from  previous  projects  affect  the  form  and  content  of  ai^ication  engineering  work  prod¬ 
ucts  for  the  targeted  project.  The  scope  of  a  domain  is  a  decision  bas^  on  eiisting  systems  and  cmgoing 
fu-ojects  within  the  organization.  Domain  Analysis  specifies  a  standardized  ^)plication  Engineering 
process  and  work  product  famUies  to  support  Af^lication  Engineering  and  verifies  that  a 
corresponding  Domain  Implementation  meets  that  specification. 

1.1  Objectives 

The  objectives  of  Domain  Analysis  are  to: 

•  Determine  scope  and  viability  of  a  domain  based  on  existing  systems,  planned  domain 
develoiMnent  and  evolution,  and  needs  of  the  targeted  project 

•  Establish,  manage,  and  evolve  a  set  of  work  product  families  representing  domain  knowledge 
perceived  relevant  to  the  targeted  project 

•  Describe  an  Application  Engineering  process  and  work  product  families  appropriate  to  the 
domain  and  relevant  to  the  targeted  project 


1.2  Required  Information 

Domain  Analysis  requires  the  following  information: 

•  Domain  Plan;  Domain  Objectives 

•  Domain  Implementation 


13  Required  Knowledge  AND  Experience 

Domain  Anafysis  requires  domain  and  software  knowledge  and  experience  in: 


Fast  and  ongoing  projects  in  the  organization 
The  needs  that  motivate  systems  in  the  domain 
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The  enviromneiits  in  which  these  ^tems  <^rate 
How  these  systems  are  built 


2.  PRODUCT  DESCRIPTION 

Domain  Analysis  creates  two  work  products:  Domain  Definition  and  Domain  ^)eci^tion. 

2.1  Domain  Dehniiion 

Pwfose  A  Domain  Definition  (see  Section  DE.2.1)  is  an  informal  description  oi  foe 

systems  and  related  ap^cation  engmeerii^  work  products  in  a  business  area 
tlut  form  a  domain.  A  Domain  Definitkm  characterizes  how  ezistii^  systmns 
and  systems  being  developed  in  ongoing  projects  in  the  (knnain  are  similar  and 
how  they  differ. 

Virtfkation  The  Domain  Definition  captures  sufficient  information  to  allow  (kMnain 

Criteria  engineers  to  describe  accurately  ai^  masting  or  potential  ^tem  (in  particular, 

the  system  being  built  by  the  targeted  project). 

2.2  Domain  Specification 

Purpose  A  Domain  Specification  (see  Section  DE22)  characterizes  work  product 

families  of  the  domain  that  are  relevant  to  foe  targeted  project  and  an 
^)plication  Engineering  process  for  constructing  members  of  the  respective 
work  product  families. 

Verification  The  Domain  Specification  precisely  expresses  the  domain  as  captured  in  foe 

Criteria  Domain  Definition. 

3.  PROCESS  DESCRIPTION 

The  Domain  Analysis  Activity  consists  of  the  three  steps  shown  in  Figure  DE.2-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Analysis  Activity. 

Step:  Domain  Definition  Activity 

Acrion  Characterize  the  domain  to  satisfy  domain  objectives  relative  to  the  targeted 

project’s  needs  (see  Section  DE2.1). 

Input  Domain  Plan 

Result  Domain  Definition 

Heuristics  •  Characterize  the  domain  by  defining  its  scope  (i.e.,  dasses  of  tystems, 

diaracteristics,  or  functions  induded  and  exduded  from  the  domain)  and 
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RgureDE^l.  DoeuinAiialyatftQceM 

how  included  systems  are  distinguished  fr<»n  one  anotfier.  These  deSnitions 
are  a  basis  fix’ judging  the  quaUteth«  and  eonoinic  characteristics  of  the  do* 
main  to  determine  wiiethCT  the  domain  as  defined  will  be  economicalty 
viable. 

•  Consider  how  the  work  jxoducts  for  the  system  needed  by  the  targeted 
[xoject  are  similar  and  distinguishable  from  work  products  of  existing 
^tems. 

•  Use  this  definition  as  a  basis  for  judging  the  qualitative  and  economic 
characteristics  of  the  domain  to  determine  whether  the  domain,  as 
defined,  will  be  economically  viable  fi>r  the  targeted  jxoject  If  anafysis  of 
the  Domain  Definition  fails  a  test  of  economic  vial^^  for  the  targeted 
project,  reevaluate  the  scope  of  the  domain  in  terms  of  domain  objectives 
relative  to  the  targeted  project's  needs. 

Step:  Domain  Specification  Activity 

Aaion  Specify  ^iplication  Engineering  Process  Su{^rt  (see  Section  DE.2.2). 

Input  Domain  Definition 

Result  Domain  Specification 

Heuristics  •  Identify  and  specify  work  [xoduct  families  apfxopriate  for  the  domain  and 

susceptible  to  reuse.  You  need  to  ensure  that  these  families  are  useful 
vdien  ai^cation  engineers  develop  api^cation  engineering  woric 
products  for  the  targeted  project 
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•  Create  a  spedfication  of  standard  suj^rt  for  A{^cation  Engineering  in 
the  domain.  This  support  desaibes  the  process  followed  to  identify  work 
products  that  jM-ovide  the  focus  of  reuse  efforts. 

•  Identify,  for  each  work  jx-oduct  family,  the  decisions  that  an  apf^cation 
engineer  must  make  to  describe  fully  the  variations  in  the  different  work 
product  families.  These  decisions  should  accommodate  aspects  apfxofxi- 
ate  for  the  work  product  family  (such  as  functional  [e.g.,  tehavioral]  and 
nonfunctional  aspects  [e.g.,  size,  timing,  fault  tolerance,  hardware  archi¬ 
tecture,  hardware/software  configuration])  so  that  the  apfdication 
engineer  can  express  his  needs. 


•  Create  standardized  designs  for  the  work  product  families.  The  designs 
must  satisfy  both  the  common  and  variable  aspects  of  the  work  produa 
family  as  perceived  relevant  to  the  targeted  project.  A  standardized  design 
includes  toth  design  structures  that  define  various  views  of  the  work  fx’od- 
uct  structure  and  components  from  v^ch  a  work  [xoduct  is  constructed 
that  might  satisfy  the  application  engineer’s  needs  for  the  targeted  project. 

Step:  Domain  Verification  Activity 


Action 


Input 


Result 

Heuristics 


Verify  the  correctness,  consistency,  and  completeness  of  domain  engineering 

work  products  (see  Section  DE.2.3  for  motivation). 

•  £>omain  Definition 

•  Domain  Specification 

•  Domain  Implementation 

None 

•  Verify  the  consistency  and  completeness  of  the  Domain  Definition. 

•  Verify  that  the  representation  of  the  Application  Engineering  process  in 
the  Domain  Specification  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Definition. 

•  Verify  that  the  representation  of  the  application  engineering  product  in 
the  Domain  Specification  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Definition. 

•  Verify  that  the  Product  Implementation  is  consistent  and  complete  with 
respect  to  the  Domain  Specification. 

•  Verify  that  the  representation  of  the  Application  Engineering  process  in 
the  Process  Support  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Specification. 


3.2  Risk  Management 

Risk  The  cost  of  an  increment  of  Domain  Analysis  is  projected  to  exceed  the  budget. 
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tm/tkadom  InsitfBdait  resources  eaast  to  ooi^ete  a  planned  iteration  ot  Doouto 

Engineering. 

h/Btigation  •  Reduce  the  current  scope. 

•  Seek  a  diange  in  domain  objectives  or  an  increase  in  the  budget  for  die 
increment  from  Domain  Management. 

4.  INTERACTIONS  WITH  OTHER  ACTTVITIES 

4.1  feedback  TO  iNFDRMAnoN  Sources 

ConBngmcy  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Domain  Definition  and  a  Domain  Specification  that 
satisfy  the  Domain  Plan  as  closely  as  possible. 

Contingency  The  Domain  Implementation  does  not  satisfy  the  Domain  Spedfication. 

Source  Domain  Implementation  Activity 

Response  Clarify  the  intent  of  the  Domain  Specification. 

Contingency  The  practices  and  procedmes  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  inefficient.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  Suggestions  are  made  for  Domain  Specification  changes  to  exploit  unforeseen 

opportunities.  For  example,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  when 
the  Domain  Specification  was  completed. 

Source  Domain  Implementation  Activify 

Response  •  Revise  the  Domain  Specification. 

•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 
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CotUi/^mcy 

Source 

Response 

Condi^ency 

Source 

Response 

Contii^ency 

Source 

Response 


The  Domain  Definition  and/or  Dmnain  Specification  fails  to  provide  the 
capabilities  required  by  the  Domain  Ban. 

Domain  Management  Activity 

Evolve  the  Domain  Definition  and  the  Domain  Specification  to  be  consistent 
with  the  Domain  Han. 

The  Domain  Spedfication  is  incomidete,  ambiguous,  or  inconsistent. 
Domain  Implementation  Activity 

Revise  the  Domain  Specification  to  correct  the  inadequades. 

The  standardized  Ap|dication  Engineering  supporting  work  products  are 
ineffident  or  lead  to  less-than-ideal  results  for  the  targeted  project. 

Project  Support  Activity 

•  Determine  that  the  benefits  of  work  product  standardization  outweigh  the 
interests  of  the  particular  project. 

•  Evolve  the  definition  of  the  Application  Engineering  supporting  work 
products  to  reflect  the  project’s  experience  or  to  be  adapted  to  the 
particular  conditions  of  concern. 
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DE.2.1.  DOMAIN  DEFINITION  ACTIVITY 


1.  GETTING  STARTED 

Domain  Definition  is  an  activity  of  Domain  Analysis  for  aeating  a  Domain  £>efinition.  A  Domain 
Definition  is  an  informal  description  of  the  systems  and  related  ai^cation  engineeringwork  products 
in  the  business  area  that  form  a  domain.  A  Domain  Definition  diaracterizes  how  systems  in  the 
domain,  as  represented  by  a  set  of  work  products,  are  similar  and  how  they  differ. 

1.1  Objectives 

The  objectives  of  the  Domain  Definition  Activity  are  to: 

•  Establish  a  conceptual  basis  and  bounds  for  more  detailed  Domain  Analysis 

•  Determine  whether  planned  development  of  the  domain  is  viable  relative  to  the  needs  of  the 
targeted  project  and  the  organization’s  reuse  objectives 

•  Establish  criteria  by  which  management  and  engineers  can  judge  whether  a  proposed  system 
is  properly  within  the  domain 

1.2  Required  Information 

The  Domain  Definition  Activity  requires  the  Domain  Flan. 

U  Required  Knowledge  AND  Experience 

The  Domain  Definition  should  be  developed  by  «q)erU  with  a  variety  of  backgrounds  in  the  domain 
understudy.  They  need  broad  domain  knowledge.  Sudi  knowledge  includes  what  systems  have  been 
built,  relevant  existing  work  products  (requirements  specification  documents,  design  documents, 
etc.),  and  the  nature  of  systems  likely  to  be  requested  and  built,  especially  by  the  targeted  project 

2.  PRODUCT  DESCRIPTION 

Name  Domain  Definition 

Purpose  A  Domain  Definition  establishes  the  scope  of  a  domain  and  a  justification  of 

its  economic  viability.  It  provides  a  basis  for  determining,  informally,  whether 
a  system  is  properly  within  that  scope. 

The  Domain  Definition  does  not  answer  detailed  questions  of  scope,  but 
clearly  includes  and  excludes  broad  dasses  of  systems  and  their  assodated 
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work  i^oducts.  Assumptions  of  commonality  and  exclusion  identify  the 
common  features  of  systems  and  work  products  in  the  domain,  therein 
establishing  a  family.  Assumptions  of  variability  identify  how  systems  and 
work  products  in  the  family  are  distinguished  from  one  another.  Justification 
provides  a  basis  for  judging  technical  and  economic  feasibility  of  the  domain 
to  evaluate  whether  there  is  sufiicient  confidence  in  the  viability  of  supporting 
work-product  reuse  by  the  targeted  project  for  a  system  in  the  domain. 

Content  A  Domain  Definition  consists  of  the  following  components: 

•  Domain  Synopsis.  An  informal  statement  of  the  scope  of  the  domain. 

•  Domain  Glossary.  Definitions  of  significant  terminology  used  by 
experts  in  discussing  needs  and  solutions  in  the  domain. 

•  Domain  Assumptions.  A  description  of  what  is  common,  variable,  and 
excluded  among  systems  in  the  domain,  as  reflected  in  their  associated 
work  products. 

•  Domain  Status.  An  assessment  of  the  current  maturity  and  viability  of 
the  domain  relative  to  its  expected  use  by  the  targeted  project. 

•  Legacy  Products.  A  representative  collection  of  work  products  from 
c  jsting  systems  in  the  product  line  which  may  be  a  suitable  source  of 
information  and  raw  material  for  developing  the  domain. 

Verification  Every  characteristic  ascribed  to  all  systems  in  the  domain  by  the  Domain 

Criteria  Synopsis  must  be  stated  as  a  Commonality  Assumption. 

2.1  Domain  Synopsis 

Purpose  The  Domain  Synopsis  is  an  informal  statement  of  the  scope  of  the  domain.  It 

characterizes  systems  included  in  the  domain  and  work  products  your 
organization  produces  during  software  development. 

Content  A  Domain  Synopsis  includes  an  informal  characterization  of  the  systems  and 

work  products  that  make  up  the  domain. 

Form  and  A  Domain  Synopsis  is  a  simple  narrative  using  terms  defined  in  the  Domain 

Structure  Glossary.  Example  DE.2.1-1  illustrates  a  fragment  of  a  Domain  Synopsis  for 

the  TLC  domain.  This  fragment  depicts  typical  information  contained  in  a 
Domain  Synopsis  and  the  use  of  terms  from  the  Domain  Glossary. 

Verification  •  The  Domain  Synopsis  must  give  an  intuitive  feel  for  the  definitive 

Criteria  characteristics  of  systems  m  the  domain,  as  reflected  in  their  associated 

work  products.  It  shoidd,  in  itself,  adequately  describe  any  existing  system 
(in  particular,  the  system  being  built  by  the  targeted  project). 

•  A  term  that  could  have  different  meanings  to  different  readers  may  be 
used  in  the  Domain  Synopsis  only  if  it  is  defined  in  the  Domain  CHossary. 
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DE2.1.  Doania  DeSa&ioa  AeMtf 


The  Irafnc  Light  Cc^itrol  Software  System  (TLC)  domain  is  a  family  of  embedded  computer  systems  to  ooQtroI  the 
operation  of  traffic  lights  at  a  given  intersection.  The  TLC  domain  is  limited  to  controlling  traffic  at  inteisectioas  of  two 
roads  with  at  most  one  road  dead-ending  at  the  intersection.  Systems  in  the  TLC  domain  contrd  traffic  at  the  intersection 
by  changing  the  indicators  of  each  traffic  light  (called  a  traffic  light  sequence).  Each  traffic  light  sequence  is  coordinated 
with  the  other  traffic  lights  in  the  intersection  to  prevent  accidents  while  vehicles  traverse  the  intersection.  Usually,  a  TLC 
^stem  generates  its  traffic  light  sequence  based  on  a  clock-generated  cycle  adiich  may  last  frmn  one  (1)  to  three  hundred 
(300)  seconds.  The  traffic  light  sequence  generated  from  the  clock  may  be  modified  based  on  signals  horn  optional  input 
devices. 

One  optional  input  device  is  a  trip  mechanism  buried  under  the  roadway.  A  trip  mechanism  may  be  associated  with  either 
a  lefi-tum  lane,  a  right-turn  lane  or  a  thru-traffic  lane.  Input  from  a  trip  mechanism  associated  with  a  left-turn  lane 
controls  whether  the  left-turn  indicator  of  the  traffic  light  is  turned  on  during  a  traffic  light  sequence.  A  trip  mechanism 
associated  with  a  right-turn  signal  may  act  in  an  analogous  manner  for  a  right-turn  signal.  Inputs  from  any  trip  mechanisms 
may  alter  the  traffic  light  sequence.  A  trip  mechanism  is  not  required  for  the  proper  operation  of  the  turn  lane. 

Another  optional  input  device  is  the  pedestrian  crosswalk  push  button.  This  input  controls  whether  the  walk/don’t  walk 
indicator  is  on  during  a  traffic  light  sequence.  It  may  also  modify  the  traffic  light  sequence.  Apush  button  b  not  required 
for  the  proper  operation  of  the  pedestrian  lane. 


Example  DE.2.1-1.  Fragment  of  TLC  Domain  Synopsis 


2.2  Domain  Glossary 


Purpose 


Content 


Form  and 
Structure 


Verification 

Criteria 


The  Domain  Glossary  is  a  compendium  of  precise  definitions  for  all  significant 
terminology  used  by  experts  for  discussing  problems  and  solutions  in  a 
domain.  This  domain  terminology  is  organized  into  a  taxonomy  of  terms. 

A  Domain  Glossary  has  two  parts: 

•  A  set  of  standard  terms  and  their  definitions 

•  A  list  of  references  to  external  sources  which  define  and  elaborate  on 
relevant  topics  and  terminology 

A  reference  to  an  external  source  is  written  using  an  accepted  documentation 
style  for  a  reference  (e.g.,  author-date).  Standard  terms  are  defined  in 
alphabetical  order  using  the  following  forms: 

Tferm  1  definition  (source) 

Term  2  (1)  first  definition  (source);  (2)  second  definition  (source) 

The  source  of  the  term’s  definition  (source)  is  listed  after  the  definition. 
Example  DE.2.1-2  illustrates  a  fragment  of  a  Domain  Glossary  for  the  TLC 
domain.  This  fragment  depicts  typical  terminology  needed  to  discuss  systems, 
problems,  and  solutions  in  the  TLC  domain. 

•  The  Domain  Glossary  must  contain  precise  definitions  of  all  significant 
terminology  used  by  domain  experts  for  discussing  the  requirements  or 
engineering  of  systems  in  the  domain  or  their  associated  work  products. 


Opp-33 


DE.2.1.  Domain  DcCniiion  Activity 


Term 

Definition 

Crosswalk 

A  qjedally  paved  (v  marked  path  for  pedestrians  crossing  a  street  or  road.^ 

Crosswalk  Push  Button 

Amonitoring  device  which  allows  a  pedestrian  to  agnal  to  the  system  his  preseixse 
at  a  crosswalk. 

Inp  Mechanism 

A  traffic  monitoring  device  used  to  determine  nhetber  a  vehide  is  present  in  a  lane. 

Irafnc  Control 

A  synchronized  set  of  traffic  light  sequences  specified  as  a  functkm  <^time  and  traffic 
monitoring  device  inputs. 

IhiBic  Light 

A  set  of  indicates  placed  at  the  intersection  c£  streets  to  regulate  traffic. 

Traffic  Light  Cycle 

One  iteration  through  a  traffic  light  sequence,  Le.,  frmn  the  di^day  of  the  red 
indicator  through  to  the  next  display  the  red  indicator. 

Traffic  Light  Sequence 

The  order  in  «hidi  a  set  of  traffic  li^t  indicators  are  disjdayed  during  a  traffic  <yde. 
'^ically,  thb  ordering  is  red,  green,  amber,  but  other  orderings  are  possible. 

Traffic  Monitoring  Device 

A  device  that  monitors  the  flow  of  traffic. 

^  Webster’s  Third  New  International  Dictionary  of  the  English  Language  Unabridged. 

Example  DE.2.1-2.  Fragment  of  TLC  Domain  Glossary 

•  Any  term  used  in  a  definition  that  could  have  different  meanings  to 
different  readers  must  also  be  defined. 

•  All  independently-used  terms  that  are  generalizations,  specializations,  or 
components  of  defined  terms  must  also  be  explicitly  defined. 

•  Terms  defined  in  the  Domain  Glossary  must  be  sufficient  for  a  domain 
expert  to  give  an  accurate  description  of  any  existing  system  an'*  ‘he  system 
being  built  by  the  targeted  project. 

23  Domain  Assumptions 

Purpose  Domain  Assumptions  desoribe  what  is  conunon  to  all  systems  or  their 

associated  work  products  in  the  domain  and  in  what  significant  ways  those 
systems  and  work  products  vary  and  can  be  distinguished.  These  assumptions 
determine,  informally,  whether  a  system,  as  represented  by  a  set  of  work 
products,  is  within  the  scope  of  the  domain. 

Content  There  are  three  types  of  assumptions: 
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Form  and 
Structure 


Verification 

Criteria 


•  AsetofassunytkMgabcHitthec^ 

that  are  common  to  all  systems  in  the  domain  and  their  associated 
work  products  (commonalities). 

•  Variability  Assumptions.  A  set  of  assumptions  about  the  diaracteristics 
that  distinguish  systems  in  the  domain  and  their  associated  work 
products  (variabilities). 

•  Exclusionaty  Assumptions.  A  set  of  assumptions  about  the  characteristics 
of  systems  and  their  associated  work  products  that  are  outside  the 
scope  of  the  domain  (exclusions). 

Every  assumption  is  composed  of  a  desCTiption  and  justification. 

Assumptions  may  also  be  elaborated  with  associated,  subordinate 
assumptions.  For  example,  a  commonality  assumption  may  have  spedfic 
variabilities  associated  with  it.  Similarly,  a  particular  resolution  of  a  variability 
assumption  can  be  thought  of  as  characterizing  a  subfamily  of  the  product 
family.  The  subfamily  then  may  have  additional,  more  specific  commonalities 
and  variabilities  that  further  distinguish  the  members  of  the  subfamily. 

An  assumption  description  and  justification  are  informal  text.  Assumptions 
which  elaborate  another  assumption  should  be  presented  in  adjacent, 
indented  text.  Examples  DE.2.1-3  and  DE.2.1-4  illustrate  fragments  of  some 
commonality  and  variability  assumptions  for  the  TLC  domain.  The 
justification  provides  rationale  on  why  the  domain  engineers  believe  the 
assumption  to  be  valid. 

•  Commonality  and  variability  assumptions  must  capture  all  important 
aspects  that  are  common  to  all  systems  in  the  domain,  as  represented  by 
a  set  of  work  products,  and  the  significant  ways  in  which  these  systems  and 
their  work  products  can  vary.  Exclusionary  assumptions  must  not  exclude 
needed  capabilities. 

•  Systems  and  their  work  products  must  only  vary  as  implied  by  the 
variability  assumptions. 

•  A  commonality  assumption  must  apply  equally  well,  without  qualification, 
to  any  system  ia  the  domain,  as  represented  by  a  given  type  of  work  prod¬ 
uct.  ^tems,  as  represented  by  their  associated  work  products,  must  not 
violate  a  stated  commonality,  either  by  excluding  an  induded  feature  in 
the  commonality  assumptions  or  by  induding  an  excluded  feature  in  the 
exclusionary  assumptions. 

•  All  reviewers  must  agree  that  domain  experts  will  consider  Domain 
Assumptions  to  be  consistent  and  unambiguous,  relative  to  the  definitions 
in  the  l^main  Glossary.  A  term  that  could  have  different  meanings  to  dif¬ 
ferent  readers  may  be  used  in  a  Domain  Assumption  only  if  it  is  defined 
in  the  Domain  Glossary. 
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DE2.1.  Domaiii  Definitioii  Activily 


•  A  TLC^emcontrds  the  traffic  light  sequeocesat  an  ffltenection. 

Just^fkatbrn  The  puipoae  of  a  HjC  qrstem  is  to  oooliol  arfhea  traffic  light  sequences  diange.  and  the 
interactkxis  of  the  traffic  l^hts  at  an  interaectiGa. 


•  A  TLC  system  coordinates  all  traffic  lights  at  an  mtersectioQ. 

JusHpeatUm  Safe  transit  of  intersection  requires  that  streams  of  traffic  not  cross,  e^^  east  bound  traffic 
and  north  bound  traffic  cannot  have  green  indicators  concurrently. 


•  The  entire  week  is  divided  into  traffic  cycles.  The  traffic  li^ts  at  the  intersection  are  ^ncfaronized  based  on 
these  traffic  ^des. 

Justification  'ffaffic  patterns  and  loads  vary  over  the  course  a  day  and  of  a  week.  The  timing  the 
traffic  cydes  must  be  varied  to  deal  with  the  variaticms  in  the  traffic  load. 


•  A  TI.C  system  must  process  signals  from  a  trip  mechanism  or  push  button  within  a  specified  time. 

Justification  Smooth  traffic  flow  depends  upon  the  TLC  system  detecting  and  reqxmding  to  requests  to 
a  traffic  light  sequence  in  a  timely  manner. 


Example  DE.2.1-3.  fragment  ofTLC  Commonality  Assumptions 

2.4  Domain  Status 

Purpose  Domain  Status  describes  the  current  technical  maturity  of  the  domain  that  the 

organization  has  achieved  relative  to  planned  evolution,  and  assesses  the 
viability  of  evolution.  Of  particular  concern  are  imsupported  variability 
assumptions  (i.e.,  default  commonalities). 

Content  The  Domain  Status  is  an  informal  characterization  of  the  degree  to  which 

Domain  Objectives  are  satisfied  by  past  development.  It  indudes  an  analysis 
of  how  well  the  needs  of  the  target^  project  are  being  met  1^  the  domain. 

Form  and  The  maturity  of  a  domain  can  be  expressed  as  limitations  in  satisfying 

Structure  variability  assumptions.  Risks  can  be  mitigated  by  imposing  limits  on 

variability  assumptions. 

2.5  Legacy  Products 

Purpose  Legacy  Products  provide  access  to  work  products  firom  existing  systems  that 

may  be  useful  sources  of  information  and  raw  material  for  developing  the 
domain. 
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•  An  intenectkn  nu^  be  fanned  from  two  through  (»>  X  iatenedioQ)^  or  from  one  dvough  road  uid  a 

dead-ending  road  (a  T  intersection). 

JusUfIcatUm 

The  number  of  roads  that  can  meet  at  an  interaectian  can  vary  from  intersection  to 
intersection.  At  least  two  roads  must  cross  to  have  an  iiUersectioLi,  but  inteiaections  of  tlnee 
or  more  roads  are  common.  The  maric^ing  department  bdieves  that  the  vast  majority  of 
intersections  are  of  the  T  and  X  variety.  It  has  decided  to  ocmoentrate  on  this  large  subset 
of  traffic  intersections. 

•  The  number  of  lanes  of  traffic  on  any  road  approaching  mr  leaving  the  mtersection  may  vary.  The  minimum 
number  of  lanes  of  traffic  is  one  (1).  The  maximum  number  is  m  (6). 

Justification 

Any  road  bringing  traffic  into  the  intersection  must  have  at  least  one  lane  of  traffic  into  the 
intersection.  Any  road  leaving  the  intersection  must  have  at  least  one  lane  of  traffic  from 
the  intersectioa  Engineering  has  determined  that  the  hardware  components  of  the  system 
cannot  control  more  than  six  lanes  of  traffic  in  a  timdy  fashion. 

•  Any  road  approaching  the  intersection  may  have  a  trip  mechanism  buried  under  the  traffic  lanes  to  alert  the 
system  to  the  presence  of  vehicular  traffic.  There  may  be  no  trip  mechanism  or  there  may  be  one  ( 1 )  per  traffic 
lane. 

Justification 

The  traffic  light  sequence  may  take  into  account  the  presence  or  absence  of  vehicular  traffic 
at  the  intersection. 

•  The  duration  of  a 

traffic  control  schedule  will  vary. 

Justification 

Traffic  patterns  and  volumes  vary  from  intersection  to  intersection.  Effective  traffic  control 
at  these  intersections  requires  schedules  that  take  these  variations  into  account  Traffic 
control  schedules  must  also  vary  to  account  for  differences  in  system  configurations. 

Example  DE.2.1-4.  Fragment  of  TLC  Variabflity  Assumptions 


Content  Legacy  Products  consists  of  a  representative  collection  of  work  products  (or 

portions  thereof)  from  existing  systems  in  the  product  line  to  be  supported  by 
the  domain. 

Form  and  •  Work  products  may  be  physically  stored,  on  paper  or  in  electronic  media. 

Structure  or  may  only  be  identifi^  by  reference  when  sufficiently  accessible  in  this 

way  (e.g.,  in  an  organization’s  local  library  or  in  an  accessible  repository 
set  up  for  another,  existing  domain). 

•  Work  products  are  kept  in  Legacy  Products  in  the  for m  in  which  they  were 
produced.  Other,  consuming  activities  of  Domain  Engineering  will  copy 
and  excerpt  or  adapt  these  work  products,  as  needed,  in  order  to  cx^eate 
reusable  assets. 
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•  The  work  products  comprising  the  Legacy  Products  are  organized  in  a 
suitable  manner  to  {vovide  access  by  other  Domain  Engineering  activities 
to  a  particular  system’s  work  products  or  to  individual  work  fn-oducts  of  a 
particular  type. 

Variation  Each  work  product  in  Legate  Products  must  come  from  an  existing  system  that 

Criteria  was  determined  to  be  in  the  domain. 

3.  PROCESS  DESCRIPTION 

The  Domain  Definition  Activity  consists  of  the  five  steps  shown  in  Figure  DE.2.1-1. 


Define  the  Dcmain 
Informally 


Establish 

Standard  Terminology 


_ I _ 

Establish 

^  Domam  ^ 

Identify  Legacy 

Domain  Assumptions 

V^Assumptkms/ 

Products 

- 1 - 

Domain  Spedficadon,  Domain  lirification,  and 
Project  Support 


to 


Domain  Management 


Figure  DE.2.1-1.  Domain  Definitioa  Rooess 


3.1  Procedure 

Follow  these  steps  for  the  Domain  Definition  Activity. 
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Aetkm  Qeate  a  desatption  of  the  (k>iiiaiii,cfaaract«izuig  key  technical  <^jectives  of 

indiuled  systems. 

Domain  Han:  Domain  Objectives 

Result  Domain  Definition:  Domain  Synopsis 

Heuristks  •  Start  with  a  one-sentence  description  the  family  of  systons  that  omstitutes 

the  domain. 

•  Refine  the  Domain  ^nopsis  to  two  pages,  at  most,  of  intuitive  and  not 
overly-restrictive  text  Impart  concisely,  an  informal  but  complete  sense 
of  the  domain  in  the  first  paragraph.  Tiy  to  focus  on  the  essential  nature, 
scope,  and  variety  of  systems  in  the  domain. 

•  Characterize  the  type  of  [voblem  that  systems  in  the  domain  solve,  and  the 
external  environment  (i.e.,  devices,  systems,  and  users)  with  which  systems 
interact.  Desaibe  the  observable  behavior  that  systems  ohibit  in  solving 
the  problem.  You  might  also  establish  significant  constraints  concerning 
how  the  systems  operate  in  terms  of  performance,  reliability,  or  distribution 
concerns. 

•  Cover  the  primary  functions  performed  by  every  system  in  the  domain  and 
any  important  functions  performed  by  only  some  systems.  Maintain  a 
black-box  perspective  vdien  describing  functional  aspects  of  the  system. 

•  Be  sure  your  descriptions  of  problems  and  functions  characterize  the 
system  to  be  produced  by  the  targeted  project. 

•  Use  terms  defined  in  the  Domain  Glossary  to  keep  the  Domain  Syno|»is 
short. 

•  If  the  domain  (e.g.,  process  control  ^tems)  is  based  on  formal  theories 
that  provide  experts  with  a  common  language  of  conununication  about 
problems,  refer  to  those  theories  in  the  Domain  Synopsis. 

Step:  Establish  Standard  Terminolt^ 

Action  Create  definitions  of  all  significant  terms  used  by  domain  experts  in  discussing 

the  requirements  or  engineering  of  systems  in  die  domain  or  their  assodated 

work  products. 

Domain  Definition:  Domain  ^opsis 

Result  Domain  Definition:  Domain  Glossary 

Heuriaics  •  Maintain  term  definitions  in  alphabetical  order  for  ease  of  reference. 

Provide  cross-references  to  related  terms. 
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•  Use  definitions  from  standard  gkrasaries  where  possible.  Make  note  of 
sudb  sources  in  each  definition  fw  future  traceability. 

•  Make  definitions  as  fvedse  as  possible. 

•  Make  sure  that  all  terminology  used  in  the  Domain  Syn<^)sis  is  defined  in 
the  Glossary. 

Step:  Establish  Domain  Assumptions 

Action  Create  lists  of  the  assumptions  that  allow  you  to  think  of  the  envisioned  set  of 

systems  as  a  family  and  the  assumptions  that  allow  you  then  to  distinguish 

among  them  and  their  associated  work  products. 

Input  •  Domain  Definition:  Domain  ^opsis 

•  Domain  Definition:  Domain  CHossary 

Result  Domain  Definition:  Domain  Assumptions 

Heuristics  •  State  only  those  assumptions  that  affect  the  system  software  and 

associated  delivered  products  (e.g.,  documentation,  test  support). 

•  Initially,  concentrate  on  assumptions  related  to  system  functionality. 
Expand  your  focus  to  design  issues  and  to  assumptions  about  related  work 
products. 

•  Assumptions  often  come  from  knovdedge  or  analyses  of  work  products  of 
Legacy  Products.  If  some  assumptions  relate  only  to  a  particular  type  of 
work  product,  then  group  those  assmnptions  apart  from  the  generally 
more  applicable  assumptions. 

•  Tb  create  a  preliminary  set  of  assumptions: 

-  Create  a  commonality  assumption  for  each  diaracteristic  specified  in 
the  Domain  Synopsis  that  is  shared  tty  all  tystems  in  the  domainu 

-  Create  a  variability  assumption  for  each  characteristic  specified  in 
the  Domain  Synopsis  that  is  not  shared  by  all  tystems  in  the  domain. 

-  For  eadi  term  in  the  Domain  CHossary,  determine  vdiether  the  tenn 
indicates  a  commonality  or  a  variability  among  systems  in  the 
domain.  Create  an  assumption  acoordin^y. 

•  Make  variability  assumptions  precise  Ity  indicating  the  type  of  dedsion  the 
application  engineer  must  make  to  resolve  the  variability.  It  is  not  suffi¬ 
cient  to  note  only  that  some  characteristic  varies.  You  must  establish  how 
much  flexibility  the  application  engineer  needs  to  characterize  different 
systems  adequately. 
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•  Elatxvate  oommonality  assumptkMis  to  unoover  q;)eGific  variaUlitM^ 
assumptknis  associated  with  them.  This  will  mcve  fvedsely  diaracterize 
a  subset  of  the  product  fomily. 

•  Elaborate  variability  assumpdcms  to  find  more  specific  commonality  and 
subsequent  variability  assumptions  that  further  distii^nish  mend>ers  of 
the  subfamily. 

•  Compare  the  characteristics  of  existing  ^ems  to  fiualitate  the  identificatkm 
of  common  features  and  variations. 

•  Distinguish  between  system-generation-time  and  run-time  variations 
when  developing  assumptions  about  variable  aspects  of  the  domain.  Tteat 
a  run-time  variation  that  is  characteristic  of  all  systems  in  the  domain  as 
a  commonality. 

•  Use  exclusionary  assumptions  to  clarify  a  domain’s  boundary.  Do  not 
enumerate  every  type  of  system  or  function  that  is  outside  the  domain. 
Rather,  exclude  explidtly  those  functions  or  characteristics  that  a  domain 
expert  might  incorrectly  assume  to  be  part  of  a  system  when  reading  the 
Domain  Synopsis.  Thus,  you  can  answer  the  question  of  whether  a  particu¬ 
lar  system  belongs  within  the  domain  more  directly  by  checking  the 
exclusions.  Exclusions  often  result  from  a  viability  analysis  of  the  domain. 

•  State  unresolved  issues  of  functionality,  design,  etc.,  from  the  targeted 
project  as  variabilify  assumptions.  This  w^  help  you  identify  the  full  range  of 
existing  work  products  that  might  meet  an  anticipated  .^jplication 
Engineering  need. 

Step:  Assess  Domain  Status 

Action  Evaluate  the  technical  maturity  of  the  domain  in  terms  of  targeted  project 

needs.  Domain  Objectives,  and  plans  for  domain  development. 

Input  •  Domain  Plan 

•  Domain  Definition:  Domain  Assumptions 

Result  Domain  Definition:  Domain  Status 

Heuristics  Domain  Status  must  result  in  an  endorsement  of  and  commitment  to  a  specific 

domain  scope  (set  of  assumptions).  This  endorsement  comes  fi:om  targeted 
project  needs,  as  tempered  by  the  intuitions  of  experienced  personnel,  and 
resource  constraints  (e.g.,  what  products  are  available).  In  other  words,  you 
should  assess  which  Itomain  Assumptions  are  currently  satisfied  versus  whidi 
should  be  satisfied.  Of  those  which  should  be  satisfied,  assess  whidi  can  be 
satisfied  using  edsting  resources  and  which  can  be  satisfied  using  resources 
presumed  to  be  available  at  some  future  date.  This  information  should  help 
you  determine  whether  the  features  assodated  with  eadi  assumption  are 
implementable,  and  the  corresponding  risk. 
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Step:  Identify  Legtcy  Products 

Action  Identify  existing  systems  in  the  [voduct  line  that  are  considered  representative 

of  the  domain  and  udiose  work  products  may  {x^ove  useful  as  sources  of 
information  and  raw  materials  in  developing  the  domain. 

Input  •  Domain  Synopsis 

•  Domain  Assumptions 

Result  Domain  Definition:  Legacy  Ih^oducts 

Heuristics  •  Use  the  Domain  Synopsis  as  a  guide  to  select  existing  systems  that  are 

within  the  domain  (or  subsystems  that  would  be  parts  of  such  systems). 

•  Based  on  Domain  Assumptions,  identify  work  products  (or  fragments,  if 
appropriate)  from  these  systems  that  reasonably  satisfy  some  or  all  of  the 
I^main  Assumptions. 

•  Create  a  brief  description  of  the  selected  systems  and  work  products  as  a 
guide  to  their  use  as  a  source  of  information  and  raw  materials  by  other 
Domain  Engineering  activities. 

3.2  Risk  Management 

Risk  There  is  a  lack  of  critical  expertise. 

Implication  The  Domain  Definition  cannot  be  completed  or  there  is  unacceptably  low 

confidence  in  the  results. 

Mitigation  •  Commit  time  and  resources  to  acquiring  the  expertise. 

•  Restrict  Domain  Assumptions  sufficiently  to  reduce  the  need  for  expertise. 

Risk  The  scope  of  the  domain  may  be  too  narrow,  precluding  useful  variations. 

Implication  •  Opportunities  for  additional  projects  are  lost. 

•  Application  engineering  projects  miss  opportunities  for  reuse. 

Mit^ation  •  Review  the  Domain  Definition  with  management  and  experienced  engineers 

to  identify  additional  variations. 

•  Include  unresolved  issues  from  the  targeted  project. 

Risk  The  scope  of  the  domain  may  be  too  broad. 

Implication  Resources  are  misapplied  to  solve  an  unnecessarily  general  problem;  the 

result  will  be  parts  that  require  so  much  hand-tailoring  that  the  cost  of  reuse 
becomes  higher  than  that  of  developing  parts  from  scratch. 
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•  Review  the  IX)mainDefimtk>n  with  nuuu^emem  and  eaqpedeacxdcsi^guie^ 
to  identify  under-constrained  Comnx»alities. 

•  Focus  variations  on  the  needs  of  the  targeted  project 

Kisk  Domain  Assumptions  are  too  precise  or  too  vague. 

Implication  Flexibility  is  reduced  unnecessarily,  or  key  decisions  are  left  to  the  discretion 

of  domain  engineers. 

Mutation  Review  the  Domain  Definition  with  management  and  experienced  engineers 

to  identify  over-  or  under-constrained  Domain  Assumptions. 

4.  INTERACTIONS  WITH  OTHER  AdWITIES 

4.1  Feei»ack  TO  Information  Sources 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Domain  Definition  that  satisfies  Domain  Objectives 
as  closely  as  possible. 

ConHngency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  ineffident. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  ineffident.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Domain  Definition  fails  to  provide  the  capabilities  required  by  the 

Domain  Plan. 

Source  Domain  Management  Activify 

Response  Evolve  the  Domain  Definition  to  be  consistent  with  the  Domain  Plan. 

Contii^ency  The  Domain  Definition  is  incomplete,  ambiguous,  inconsistent,  or  incorrect. 

Source  •  Domain  Spedfication  Activity 

•  Domain  Verification  Activity 

Response  Revise  the  Domain  Definition  to  correct  the  inadequades. 
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DE.2.2.  DOMAIN  SPECIFICATION  ACTIVITY 


1.  GETTING  STARTED 

The  Domain  Specification  Activity  is  an  activity  of  Domain  Analysis  for  creating  a  Domain 
Specification.  A  Domain  Specification  is  a  description  of  the  Applicati  jn  Engineering  process  for  a 
domain  and  a  definition  of  a  collection  of  work  product  families  that  support  reuse  within  that  process. 
The  Application  Engineering  process  used  by  projects  in  the  domain  determines  the  types  of  work 
products  whose  creation  could  be  supported  by  reuse.  For  targeted  application  engineering  {projects, 
those  work  products  that  offer  the  greatest  opportunities  for  reuse  are  designated  for  formulation  as 
a  family. 

A  description  of  a  work  product  family  consists  of  a  description  of  how  members  of  the  family  vary, 
an  abstract  of  the  content  of  its  members,  and  a  specification  of  the  design  (i.e.,  composition  and  struc¬ 
ture)  of  its  members.  The  descriptions  of  content  and  design  must  allow  for  the  diversity  among 
members  indicated  by  the  described  variation  in  the  family. 

1.1  Objectives 

The  objectives  of  the  Domain  Specification  Activity  arc  to: 

•  Create  a  precise  specification  of  the  work  product  families  that  Domain  Engineering  provides 
to  application  engineering  projects 

•  Identify  a  collection  of  work  product  families  that  will  provide  targeted  application 
engineering  projects  with  optimal  reuse  opportunities  within  their  existing  process 

1.2  Required  Information 

The  Domain  Specification  Activity  requires  the  Domain  Definition. 

13  Required  Knowledge  AND  Experience 

The  Domain  Specification  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  Fast  and  current  systems  in  the  domain 

•  The  process  that  projects  in  the  organization  use  to  construct  application  engineering  work 
projects 

•  Creating  work  products  upon  which  reuse  in  the  domain  is  to  be  based;  mcpertise  in  what 
motivates  differences  in  their  form  and  content 
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The  concepts  and  structures  that  are  convenient  forms  v«^ch  to  communicate  about  the 
distinguishing  features  of  work  products  in  the  domain 


2.  PRODUCT  DESCRIPTION 


Name 

Purpose 


Content 


Verification 

Criteria 


Domain  Specification 

A  Domain  Specifiaition  is  a  description  of  the  Af^lication  Engineering 
process  for  a  domain  and  a  set  of  work  product  families  that  support  reuse  in 
that  domain.  Domain  Specification  identifies  a  collection  of  wcwk  product 
families  which  the  targeted  project  can  reuse  (through  adai^tion  aiKl 
tailoring)  to  produce  individual  work  products  that  meet  the  needs  of  its 
particular  customer. 

A  Domain  Specification  consists  of  one  of  each  of  the  following  components: 

•  Decision  Modd.  A  Decision  Model  identifies,  for  each  work  product 
family,  the  application  engineering  requirements  and  engineering  de¬ 
cisions  that  determine  how  members  of  the  work  product  family  can 
vary  (see  Section  DE.2.2.1).  A  Decision  Model  has  one  component  for 
each  supported  work  product  family. 

•  Product  Requirements.  Product  Requirements  describe,  for  each  work 
product  family,  the  abstracted  content  of  the  members  of  the  family 
(see  Section  DE.2.2.2).  Product  Requirements  have  one  component 
for  each  supported  work  product  family. 

•  Process  Requirements.  Process  Requirements  describe  the  established 
process  of  implication  Engineering  within  a  domain  (see  Section 
DE.2.2J3).  It  identifies  the  Qpes  of  work  i»’oducts  produced,  and  the 
types  of  work  products  for  whidi  families  may  be  provided. 

•  Product  Design,  A  Product  Design  determines,  for  each  work  product 
family,  the  structure  and  composition  of  solutions  provided  by  mem¬ 
bers  of  the  work  product  family  (see  Section  DE.2.2.4).  A  Product 
Design  has  one  component  for  ea^  supported  work  product  family. 

Problems  and  solutions  typical  both  of  existing  application  engineering  work 
projects  and  of  the  needs  of  the  targeted  project  are  adequately  addressed 
within  the  perspective  of  the  Domain  Specification. 


3.  PROCESS  DESCRIPTION 

The  Domain  Specification  Activity  consists  of  the  five  steps  shown  in  Figure  DE.2.2-1. 
3.1  Procedure 

Follow  these  steps  for  the  Domain  Specification  Activity. 
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step:  Process  Requirements  Activity 

Action  Describe  the  process  and  work  products  of  Application  Engineering. 

Input  Domain  Definition 

BesuU  Process  Requirements 

Heuristics  •  Identify  the  types  of  work  products,  resulting  from  the  Apf^ication 

Engineering  process,  that  are  normally  used  by  projects  in  the  domain. 


rojj.  DoMtfaSpaciflcHioa 


Make  allowance  for  any  deviations  known  to  be  required  the  targeted 
project. 

•  Determine  how  the  process  of  work  {xoduct  develqnnent  used  by  individual 
application  engineers  is  to  be  modified  to  exploit  reuse  opportunities. 
Section  AE  provides  a  description  of  a  typical  process  modified  for  reuse. 

Step:  Identify  Work  Product  Families 

Action  Identify  work  product  families  targeted  as  the  focus  for  increasing 

opportunities  for  reuse. 

Input  Process  Requirements 

Result  None 

Heuristics  •  Identify  those  work  product  families  that  offer  the  best  opportunities  for 

reuse  by  the  targeted  application  engineering  project. 

•  A  survey  of  existing  work  products  is  the  primary  basis  for  determining 
which  types  of  work  products  should  be  supported  with  families.  Fbcus  the 
survey  on  what  is  available  and  what  the  targeted  project  will  need. 

Step:  Decision  Model  Activity 

Action  Define  the  set  of  requirements  and  engineering  decisions  that  an  application 

engineer  must  resolve  to  select  an  instance  from  a  designated  work  product 
family. 

Input  Domain  Definition 

Result  Decision  Model 

Heuristics  •  Perform  this  step  for  each  designated  work  product  family.  Define  the 

decisions  that  lead  to  expected  differences  among  the  members  of  the  family. 

•  A  Decision  Model  for  a  work  product  family  should  reflect  the  decisions 
that  application  engineers  had  to  make  when  creating  such  work  products 
in  previous  projects. 

•  The  Dedsion  Model  for  a  work  product  family  should  reflect  the  variability 
assumptions  from  the  Domain  Definition  that  are  relevant  to  this  particular 
work  product  family. 

•  Ensure  that  supported  decisions  are  sufficient  to  distinguish  each  existing 
work  product  from  other  members  of  the  family. 

•  Identify  logical  relationships  among  the  decisions  that  characterize  a  work 
product  family  and  use  them  to  structure  the  Decision  Model.  Such  rela¬ 
tionships  can  reduce  the  munber  and  complexity  of  separate  decisions  that 
application  engineers  have  to  make. 
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St^  Product  Reqairemeats  Activity 


Aetirm 

Describe  the  omtent,  in  abstracted  form,  of  the  members  of  a  de^nated  w»k 
product  family. 

Input 

•  Dmnain  Definitkm 

•  Decision  Model 

Rmit 

Product  Requirements 

Heuristics 

•  Perform  this  step  for  eadi  suf^xMrted  work  {X’oduct  family.  Describe  the 
content  of  family  members  as  briefly  as  possible  without  omitting  key  in¬ 
formation. 

•  lb  the  degree  that  application  engineering  decisions  change  work  product 
content,  describe  how  omtent  varies  with  respect  to  those  dedsions.  This 
desoiption  will  provide  a  partial  basis  for  exi^aining  the  meaning  of 
decisions  to  application  engineers. 

Step:  Product  Design  Activity 

Action 

Define  the  design  (i.e.,  composition  and  structure)  of  the  members  of  a 
designated  work  product  family. 

Input 

•  Dedsion  Model 

•  Product  Requirements 

•  Domain  Definition:  Legacty  Products 

Result 

Product  Design 

Heuristics  •  Fcrform  this  step  for  eadi  supported  work  jvoductfamity.  Create  a  design 

for  the  work  product  family.  An  annotated  outline  is  one  model  of  a  Prod¬ 
uct  Design  for  a  document  work  product  famity.  An  information  hiding 
structure  and  process  structure  from  the  Ada-ba^  Design  for  Real-Ume 
Systems  (ADAPTS® )  (Software  Productivity  Consortium  1993)  design 
method  are  models  of  a  Product  Design  for  a  software  work  jn-oduct  fami- 
ly.. 

•  A  k^  element  of  domain  knowledge  is  how  existing  instances  of  the 
designated  work  product  family  are  designed.  When  feasible,  derive  the 
initial  Product  D^ign  for  a  famity  by  extracting  the  design  essentials  of 
odsting  instances.  Ensure  that  the  composition  and  structure  of  odsting 
instances  are  appropriately  reflected  in  the  design. 

•  lb  the  degree  that  >^^cation  Engineering  decisions  dumge  wmk 
product  composition  and  structure,  describe  how  composition  and  struc¬ 
ture  vary  with  respect  to  those  dedsions.  This  descripdtm  will  provkle  a 


further,  but  still  partial,  basis  f<x  explaining  the  mianing  Af  to 

allocation  en^eers. 


3.2  Risk  Management 

Sisk  The  Domain  Spedfication  does  not  accommodate  work  products  that  meets 

the  needs  of  the  targeted  apidication  engineering  project. 

Implication  The  domain  will  not  provide  sufBdent  opportunities  for  reuse  by  the  targeted 

project. 

Mit^ation  Compare  previously  developed  ap|dication  engineering  work  fn’ojects  that 

should  be  within  supported  families  with  expected  needs  of  the  targeted 
project.  Check  that  likely  differences  are  accommodated. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 


Contingency  The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Domain  Definition  Activity 


Response 

Contingency 

Source 

Response 

Conti^ency 


Describe  the  inadequades  in  the  Domain  Definition.  Proceed  with  Domain 
Spedfication,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Domain  Defim'tion. 

The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 
Domain  Management  Activity 

D-opose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  availaUe 
cap^ilities.  Conqdete  a  Dcxnain  Spedficaticm  that  satisfies  the  Domain  Plan  as 
dosety  as  possible. 

The  practices  and  procedures  spedfied  in  the  Domain  Plan  are  either 
ineffective  or  ineffident. 


Source  Domain  Management  Activity 

Respond  Describe  the  ways  in  whidi  the  practices  and  procedtires  are  either  ineffective 

or  ineffident.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 


4.2  Feedback  From  Product  Consumers 

Contir^ency  Suggestions  are  made  for  Domain  Spedfication  dianges  to  exploit  imforeseen 

opportunities.  For  example,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  vdien 
the  Domain  Spedfication  was  comideted. 
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Source 

Response 


Contu^ency 

Source 

Response 

Contingency 

Source 

Response 

Contit^ency 

Source 

Response 

Contingency 

Source 

Response 


Domain  Implementation  Activity 

•  Revise  the  Domain  Spedfication. 

•  Refer  opportunities  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

The  Domain  Specification  fails  to  provide  the  capabilities  required  by  the 
Domain  Plan. 

Domain  Management  Activity 

Evolve  the  Domain  Specification  to  be  consistent  with  the  Domain  Ran. 

The  Domain  Specification  for  a  work  product  family  is  incomplete, 
ambiguous,  inconsistent,  or  incorrect 

•  Domain  Implementation  Activity 

•  Domain  Verification  Activity 

Refine  the  Domain  Specification  to  correct  any  inadequacies. 

The  standardized  Application  Engineering  process  for  developing  application 
engineering  work  projects  from  a  supported  work  product  family  is  inefficient 
or  leads  to  less-than-ideal  results  for  the  targeted  project. 

Project  Support  Activity 

Revise  the  Application  Engineering  process  to  reflect  the  problems 
encountered. 

Supported  work  product  families  are  not  useful  for  the  targeted  project. 
Project  Support  Activity 

•  Determine  that  the  nature  of  the  problem  and  the  consequent  costs  of 
upgrading  the  work  product  families  outweigh  opeaed  benefits  to  the  tar¬ 
geted  project. 

•  Evolve  the  domain  engineering  work  product  family  to  reflect  this  project's 
experience  or  to  be  more  flexible  under  the  particular  conditions  of  concern. 
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DE.2.2.1.  DECISION  MODEL  ACTIVITY 


1.  GETTING  STARTED 

The  Dedsion  Model  Activity  is  an  activity  of  the  Domain  Specification  Activity  for  iM-oducing  a 
Dedsion  Model.  A  Decision  Model  defines  the  set  of  requirements  and  engineering  dedsions  that 
an  application  engineer  must  resolve  to  desoibe  and  construct  a  draft  application  engineering  work 
product.  A  Dedsion  MMel  is  an  elaboration  of  a  domain’s  variability  assumptions  and  is  the  abstract 
form  (i.e.,  concepts  and  structures)  of  an  Application  Modeling  Notation  for  a  work  product  family. 
These  dedsions,  and  the  logical  relationships  among  them,  determine  the  variety  of  work  (voducts 
in  the  domain.  Tb  construct  a  work  product,  these  dedsions  must  be  suffident  to  distinguish  the  work 
product  from  all  other  members  of  the  family.  The  dedsions  establish  how  work  products  of 
application  engineering,  including  software  and  documentation,  can  vary  in  form  and  content. 

The  Decision  Model  Activity  is  performed  for  each  targeted  work  product  family  in  the  domain. 
Consequently,  there  will  be  a  Dedsion  Model  (i.e.,  dedsions  and  logical  relationships  among  them)  for  each 
targeted  work  product  family.  The  work  product  family’s  Decision  Model  is  viewed  as  a  partition  of  the  do¬ 
main’s  Dedsion  Model.  The  focus  of  the  interactions  with  other  Synthesis  activities  occurs  at  the  work 
product  family’s  Dedsion  Model. 

1.1  Objectives 

The  Dedsion  Model  Activity  defines  a  set  of  dedsions  that  are  adequate  to  distinguish  among  the 
members  of  an  application  engineering  work  product  family  and  to  guide  adaptation  of  Adaptable 
Components  that  are  composed  to  form  application  engineering  work  products. 

1.2  Required  Information 

The  Dedsion  Model  Activity  requires  the  Domain  Definition. 

13  Required  Knowledge  AND  Experidice 

The  Decision  Model  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  Conceptual  modeling  skills  similar  to  those  needed  to  create  a  database  conceptual  schema; 
see,  for  example,  Kent  (1978)  and  Borgida  (1985) 

•  The  issues  that  experienced  engineers  resolve  when  constructing  systems  in  the  domain 

2.  PRODUCT  DESCRIPTION 

Name  Dedsion  Model 
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EUciiioaliadrtiteM^ 


Purpose 


Content 


Form  and 
Structure 


A  Decision  Model  specifies  the  decisions  that  the  ^)[dication  Modeling 
Notation  must  allow  an  a(^cation  engineer  to  make  in  describing  an  instance 
of  a  work  product.  These  dedsions  determine  the  otent  of  variation  in  form 
and  content  that  is  possible  in  the  work  {H’oduct  belonging  to  the  family. 

To  interpret  fully  the  effects  of  decisions  (i.e.,  to  understand  all  properties  of 
the  family  member  identified  by  a  set  of  decisions)  requires  both  a  Dedsion 
Model  and  a  Product  Requirements.  The  Decision  M^el  spedfies  only  the 
variations  among  members  of  a  family.  It  does  not  specify  their  common 
properties.  Product  Requirements  state  the  common  properties,  plus  the 
efi^ects  of  the  dedsions  in  a  Dedsion  Model. 

The  Dedsion  Model  work  product  consists  of  three  components: 

•  Decision  Specifications.  Specifications  of  the  set  of  dedsions  that  suffice 
to  distinguish  among  members  of  a  work  product  family. 

•  Decision  Groups.  A  structuring  of  the  dedsion  spedfications  into 
logical  groups,  based  on  domain-related  criteria. 

•  Decision  Constraints.  A  set  of  constraints  on  the  resolution  of 
interdependent  decisions. 

A  Dedsion  Model  can  be  represented  by  one  of  the  following  forms: 

•  List  of  questions 

•  Tkbular  format 

In  the  question-list  format,  each  dedsion  is  phrased  as  a  question  and  a 
non-empty  set  of  valid  answers.  The  question  identifies  the  dedsion  that  an 
application  engineer  must  make.  The  set  states  all  permissible  answers  to  that 
question. 

In  the  tabular  format,  each  horizontal  row  in  the  table  expresses  a  decision 
spedfication.  The  horizontal  row  is  divided  into  columns.  A  column  identifies 
either  the  dedsion  that  an  application  engineer  must  make,  the  permissible 
answers  for  that  dedsion,  or  a  brief  description  of  the  dedsion. 

Each  dedsion  and  each  dedsion  group  must  have  a  unique  identifier.  Domain 
engineers  use  this  identifier  when  th^  define  adaptable  work  products.  Each 
dedsion  group  has  one  list  or  table  that  is  labeled  with  a  mnemonic 
appropriate  to  the  group.  The  group  is  a  set  of  related  dedsions.  Each  entry 
is  an  independent  dedsion  that  has  its  own  distinct  mnemonic  label,  a 
spedfication  of  allowed  values  that  can  resolve  the  decision,  and  a  short 
oqjlanation  of  the  meaning  of  the  dedsion. 

If  a  set  of  related  dedsions  is  always  resolved  as  a  unit,  you  can  define  the  set  to 
be  a  composite  decision.  Composite  dedsions  are  shown  in  tabular  form  using  a 
combination  of  the  composite  of  indicator  and  indentation.  If  the  aj^cation 
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engineer  can  dKX)se  to  resolve  one  (and  only  one)  ttedsion  frcan  a  set  of 
alternatives,  you  can  define  the  set  to  be  an  aJtemative  decision.  Alternative 
dedsions  are  shown  in  tabular  form  using  a  combination  of  the  alternative  cji 
indicator  and  indentation. 

You  can  also  use  a  tabular  format  to  spedfy  constraints  on  dedsion  making. 
Dedsion  constraints  may  be  either  structural  or  dependent^.  In  both  cases,  a 
dedsion  group  (the  Dedsion  Group  column)  is  spedfied  as  the  focus  of  the 
dedsion  constraint.  A  structural  constraint  is  a  dedsion  constraint  that  limits 
the  number  of  instances  of  a  dedsion  group  in  an  ^plication  Model.  \^lid 
entries  include  exactly-one,  one-or-more,  zero-or-one,  zero-or-more,  and 
one-for-each  X,  where  X  corresponds  to  other  identified  dedsion  groups.  A 
dependency  constraint  is  a  dedsion  constraint  that  specifies  how  dedsions 
made  by  an  application  en^eer  affect  subsequent  decisions. 

Example  DE.2.2.1-1  illustrates  a  fragment  of  a  Dedsion  Model  for  a  work 
product  family  of  the  TLC  domain.  The  figure  portrays  dedsion  groups  (e.g.. 
Street,  Lane_Group)  and  their  corresponding  dedsions,  along  with 
appropriate  constraints. 


TLC_SSS:  composed  c( 

Geometiy:  one  of 

X:  list  length  4  of  Street 

H  list  length  3  of  Street 

HW_Platform:  composed  aS 

'platform:  one  of  (ILCl,  TLC2,  TLC3) 
Interface:  one  of  (IL-A,  IL-B) 

{intersection  geometry) 

{street  characteristics  for  an  X  intersection) 

{street  characteristics  for  a  T  intersection) 

{hardware  |datfotm  the  software  will  execute  on) 

{type  of  interface  to  traffic  light  indicators) 

Street:  composed  of 

Throu^_Lanes:  Lane_Group 
Left_Tum_Lanes:  Lane_Group 
Right_Tbm_Lanes:  Lane_Group 
Pedestrian_Lane:  PL_Group 

{characteristics  for  the  thru  lanes) 

{diaracteristics  for  the  left-haixl  turn  lanes) 

{diaracteristics  fcv  the  right-haixi  turn  lanes) 

{characteristics  of  a  pedestrian  lane) 

Lane_Group:  composed  of 

'IHp_Mecfaanism:  one  of  fres,  no) 

Him_Light:  <me  of  ^es,  no) 

{designates  whether  the  lanes  have  a  trip  mechanism) 
{derignates  whether  the  lanes  have  a  separate  turn  lighf) 

PL_Group:  composed  of 

Push_Button_Mecfaanism:  one  (yes,  no) 

{designates  vdiether  the  pedestrian  lanes  have  a  push 
buttcm  mechanism) 

Constraints 

—  A  Through.Lanes  group  must  be  specified  for  each  Street. 

Example  DE.2.2.1-1.  Firagment  of  TLC  Decbimr  Model  for  the  System/Segment  Work  Product  Family 
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^r^kalkm  •  Every  decision  imist  be  an  dabwatbn  of  one  or  more  varial^^ 

Crttaia  assumf^ons  or  reflect  variations  that  are  characteristic  of  existing  w(»rk 

product  family  mend)ers. 

•  All  Domain  Assumptions  pertinrat  to  the  work  {voduct  family  must  be 
elaborated  in  at  least  one  decision. 

3.  PROCESS  DESCRIPTION 

The  Decision  Model  Activity  consists  of  three  steps  shown  in  Figure  DE.2.2.1-1. 


i 


to 

Product  Requirements,  Process  Requirements, 

Product  Design,  tmd  Product  Impiementation 

Figure  DE.2.2.1-1.  Decision  Model  IVooess 

3.1  Procedure 

Follow  these  steps  for  Decision  Model  Activity. 

Step:  Identify  Decisions 

Action  Identify  the  decisions  that  application  engineers  can  make  to  resolve  all  of  the 

variations  for  a  work  product  of  a  system  in  the  domain. 

Irgwt  Variability  assumptions 

Result  Decision  specifications 

Heuristics  •  Derive  decisions  directly  from  variability  assumptions.  You  will  likely 

derive  multiple  dedsions  from  a  single  variability  assumption;  each 
dedsion  is  an  elaboration  of  some  aspect  of  the  basic  variabilify. 
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•  Derive  decisions  by  eaamining  relevant  work  products  of  existing  systems. 
Even  when  you  derive  decisions  from  variability  assumptions,  you  slK>uld 
examine  these  work  product  to  help  you  understand  how  to  exf^ess  deci¬ 
sion  specifications  in  a  form  that  is  natural  to  the  domain  (e.g.,  data  types, 
units). 

•  When  you  derive  decisions  by  examining  existing  work  products,  use 
domain  concepts  to  express  the  value  space  of  the  answers.  This  will  help 
application  engineers  resolve  decisions.  In  other  words,  if  you  have  three 
work  products  that  are  members  of  the  same  family,  identify  values  for 
answers  that  suggest  differences  among  the  work  products. 

•  Keep  in  mind  that  the  relevant  decisions  are  those  concerning  system 
generation  time,  rather  than  run-time  variation.  If  you  followed  a  similar 
heuristic  in  identifying  Domain  Assumptions,  nm-time  decisions  should 
not  be  an  issue  here.  Your  focus  now  should  be  on  how  members  of  a  work 
product  family  differ,  rather  than  on  ways  in  which  a  member  varies  its  be¬ 
havior  at  run-time.  However,  if  members  of  a  work  product  family  have 
variable  run-time  behavior,  then  a  valid  decision  may  concern  whether  or 
how  a  particular  member  varies  its  behavior. 

•  If  a  variability  assumption  asserts  that  a  certain  characteristic  of  systems 
in  the  domain  is  variable  without  saying  exactly  how  it  varies,  you  must  de¬ 
termine  exactly  how  the  characteristic  can  vary  with  respect  to  the  work 
product  family  you  are  analyzing.  Specify  the  precise  type  of  information 
that  will  resolve  a  decision. 

•  Avoid  routinely  providing  decisions  that  dictate  arbitraiy  implementation 
limits  (e.g.,  maximum  number  of  users)  unless  those  limits  reflect  a  policy 
decision.  Optimization  of  a  system  requires  adequate  flexibility. 

•  Create  a  separate  Decision  Model  for  each  application  engineering  work 
product  family.  However,  you  will  probably  want  to  share  decision  specifi¬ 
cations  across  the  models,  especially  for  work  product  families  of  the  same 
types  (e.g.,  families  of  code). 

•  When  you  examine  existing  work  products,  you  sometimes  gain  a  fuller 
understanding  of  differences  by  analyzing  and  comparing  their  structure. 
Structural  analysis  is  part  of  the  Product  Architecture  Activity.  Verify  the 
completeness  of  your  Decision  Model  using  the  knowledge  gained  from 
performing  the  Ftoduct  Architecture  Activify. 

•  Derive  at  least  one  dedsion  from  every  variability  assumption  that  the 
Domain  Plan  says  you  are  to  support.  You  need  not  elaborate  the  answers 
for  a  decision  if  you  do  not  fully  understand  its  range.  Instead,  you  can 
choose  an  answer  that  arbitrarily  fixes  the  decision.  The  Decision  Model, 
therefore,  contains  the  normal  set  of  dedsions  an  application  engineer  ex¬ 
pects  to  make  vriien  building  a  work  product  in  the  domain.  Thus,  he  can 
follow  a  familiar  dedsion-making  process. 
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Step:  StrnctHre  DedsiMis 


Action  Organize  dedsions  into  lo^cally-related  and  interconneded  groups, 

/apitf  Decision  specifications 

Result  Decision  groui» 


Heuristics 


•  Each  decision  group  should  represent  a  coherent  and  cohesive  concept  to 
domain  experts.  Such  concepts  usually  have  recognizable  names.  A  con¬ 
cept  may  be  independent  of  other  concepts,  or  may  be  an  aggregate  con¬ 
cept  that  unifies  other  simfder  concepts.  In  other  words,  a  decision  group 
may  indude  both  individual  dedsions  and  dedsion  groups  as  elements. 

•  Structure  the  set  of  decisions  based  on  the  prindf^e  of  separation  of 
concerns  (Dijkstra,  Dahl,  and  Hoare,  eds.  1972).  For  example,  create  a  de¬ 
dsion  group  for  dedsions  that  correspond  to  features  of  a  single, 
physically-distinct  entity. 

•  Group  together  mutually-dependent  dedsions,  i.e.,  those  that  are  unlikely 
to  change  independently.  Domain  experts  often  rely  on  a  single  concept 
that  ties  dependent  dedsions  together. 

•  Group  together  dedsions  that  repeat.  For  example,  if  you  need  to  describe 
multiple  types  of  a  particular  device,  the  engineer  may  make  similar 
dedsions  for  each  type.  You  can  group  these  dedsions  to  o-eate  a  single 
concept  as  a  focus  for  dedsions. 

•  Group  together  dedsions  if  they  are  derived  either  from  a  corresponding 
single  variability  assumption  or  firom  separate  assumptions  that  were 
grouped  in  the  Domain  Definition.  A  single  assumption  that  motivates 
several  dedsions  often  represents  a  single  concept,  while  assumption 
groupings  often  suggest  how  domain  experts  organize  their  thoughts  about 
such  systems. 

•  The  prindples  of  database  schema  normalization  form  a  valid  model  for 
this  step.  As  is  the  case  with  normalization,  the  goal  here  is  to  identify  and 
organize  a  set  of  concepts  without  redundancy  or  inconsistency. 

•  Define  explidt  Ic^cal  connections  between  the  dedsion  groups.  These 
define  the  relationships  between  the  dedsion  groups. 


Step:  Identify  Decision  Constraints 


Action 

Itgnit 

Result 


Define  structural  and  dependency  constraints  that  limit  how  dedsions  are 
resolved. 

Dedsion  groups 

Dedsion  Model 
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Heuristics  •  Define  a  structural  constraint  for  each  decision  group:  specify  limits  on 

when  the  group  can  validly  occur  in  an  Application  Model. 

•  Define  a  dependency  constraint  whenever  one  decision  narrcws  the 
resolution  that  the  application  engineer  can  provide  for  another  decision. 

•  You  may  sometimes  create  decision  groups  where  the  cross-product  of  the 
decision  specifications  implies  family  members  that  do  not  exist.  You 
should  examine  existing  work  products  and  specify  constraints  that  omit 
these  members  from  the  Decision  Model. 

3.2  Risk  Management 

The  Decision  Model  is  inadequate  for  descriptions  of  existing  application 
engineering  work  products. 

The  domain  will  not  provide  effective  support  for  the  targeted  project. 

Ty  to  describe  one  or  more  existing  work  products  in  terms  of  the  Decision 
Model.  Review  these  descriptions  with  experienced  engineers  from  the 
targeted  project  to  identify  erroneous  assumptions  oi  unacceptable 
limitations. 

The  decision  space  is  too  large  or  complex. 

Effort  required  to  develop  the  Decision  Model  and  subsequent  adaptable 
work  products  will  exceed  a  reasonable  level. 

•  Focus  on  a  set  of  well-understood  decisions  and  make  the  assumption, 
explicitly,  that  the  other  decisions  have  fixed  values  (i.e.,  temporarily 
constrain  them  to  be  commonalities).  Plan  to  relax  these  assumptions  in 
subsequent  iterations,  or,  in  extreme  cases,  suggest  that  the  Domain 
Definition  Activity  consider  narrowing  the  domain  scope. 

•  Reorganize  the  decision  space  to  achieve  a  more  effective  separation  of 
concerns. 

•  Introduce  an  indexing  scheme  into  the  decision  groups  (or  use  a  more 
sophisticated  one). 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Domain  Definition  Activity 

Response  Describe  the  inadequacies  in  the  Domain  Definition  and  suggest  appropriate 

refinements.  Proceed  with  Dedsion  Model,  and  document  any  assumptions 
made  regarding  the  inadequate  portions  of  the  Domain  Definition. 


Risk 

Implication 

Mitigation 

Risk 

Implication 

Mitigation 
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Cot^ngency  The  Domain  Han  cannot  be  satisfied  with  available  tedinical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Decision  Model  that  satisfies  the  Domain  Plan  as 
closely  as  possible. 

Cotaingency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  inefficient.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Decision  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Source  •  Product  Requirements  Activity 

•  Process  Requirements  Activity 

•  Product  Design  Activity 

•  Product  Implementation  Activity 

Response  Refine  the  Decision  Model  to  correct  inadequacies. 
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D£^  J.2.  PRODUCT  REQUIREMENTS  ACTIVITY 


1.  GETTING  STARTED 

The  Product  Requirements  Activity  is  an  activity  of  the  Domain  Specification  Activity  for  aeating 
Product  Requirements.  A  requirements  specification  describes  nee^  that  are  satisfied  by  creating  a 
work  product.  Similarly,  Product  Requirements  is  a  requirements  specification  that  is  adaptable  to 
the  decisions  supported  by  the  work  product  family’s  Decision  Model.  The  Product  Requirements  de¬ 
scribes  the  set  of  problems  solved  by  the  members  of  a  work  product  family.  By  applying  the  dedsions 
that  characterize  a  particular  work  product  (i.e.,  its  Application  Model)  to  the  Product  Requirements, 
a  standardized  description  of  that  work  product  is  produced.  A  Product  Requirements  gives  meaning 
to  an  Application  Model  as  a  description  of  a  member  of  a  work  product  family.  The  Product 
Requirements  Activity  is  performed  for  each  work  product  family  in  the  domain. 

1.1  Objectives 

The  objective  of  the  Product  Requirements  Activity  is  to  define  the  requirements  for  a  work  product 
family  described  in  Process  Requirements.  The  specification  must  be  adaptable  to  dedsions  allowed  Ity 
the  work  product  family’s  Dedsion  Model. 

1.2  Required  iNFORMAnoN 

The  Product  Requirements  Activity  requires  the  following  information: 

•  Domain  Definition 

•  Dedsion  Model 

U  Required  Knowledge  AND  Experience 

The  Product  Requirements  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  The  nature,  purpose,  and  use  of  work  products  for  easting  applications 

•  The  issues  that  application  engineers  must  resolve  in  creating  work  products  in  the  domain 

•  The  prindples  and  use  of  an  appropriate  specification  method  (e.g.,  informal,  structured, 
semi-formal,  or  formal) 

2.  PRODUCT  DESCRIPTION 

Name  Product  Requirements 
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Purpose 


Content 


Form  and 
Structure 


Product  Requirements  specify  the  requirements  of  members  of  a  wcx^kproduct 
family.  Product  Requirements  also  define  the  meaning  of  an  Application 
Model  created  in  accordance  with  the  corresponding  work  product  family’s 
Decision  Model.  You  can  use  the  Product  Requirements  to  understand  (and 
explain  to  ap>plication  engineers)  the  implications  of  decisions  in  an 
Application  Model  (which  describes  the  problem  solved  by  a  work  product). 

The  Product  Requirements  is  an  adaptable  requirements  specification  for  a 
work  product  family.  A  specification  contains  four  fyp>es  of  information: 

•  Concept.  An  overall  characterization  of  purpose  and  objectives. 

•  Context.  A  diaracterization  of  the  relevant  environment  and 
relationships  within  it 

•  Content.  A  characterization  of  the  expressed  or  contained  substance, 
meaning  or  behavior,  and  scop)e. 

•  Constraints.  A  characterization  of  limits  and  demands  on  context  of  use 
or  content. 

As  a  whole,  this  information  is  sufficient  to  characterize  each  particular 
member  of  a  work  product  family  as  implied  by  the  decisions  allowed  by  the 
family’s  Decision  Model. 

Product  Requirements  may  be  expressed  in  any  well-defined  form,  for 
example: 

•  Structured,  informal  text 

•  Assertions 

•  A  formal  or  semi-formal  spiecification 

The  assertions  form  of  Product  Requirements  is  a  set  of  assertions  that 
describe  the  (black-box)  meaning  of  work  products  in  the  domain.  Assertions 
may  be  simple  or  parameterized  to  reflect  decisions  defined  in  the  Decision 
Model.  Assertions  can  be  structured  into  a  hierarchy  to  facilitate  separation 
of  concerns. 

Appropriate  formal  or  semi-formal  notations  depiend  on  the  domain  being 
analyzed,  the  application  engineering  work  products  mandated  by  Process 
Requirements,  and  the  odsting  work  products  available  for  analysis.  For 
example,  when  writing  the  Product  Requirements  for  a  family  of  code,  you 
might  want  to  represent  the  Product  Requirements  using  a  package  interface 
specification  like  that  of  Booch  (1987).  lb  define  behavior  precisely,  you  might 
choose  a  semi-formal  method  as  described  in  Heninger  (19^). 

For  all  forms,  parameterization  can  be  used  to  express  the  effects  of  decisions 
on  Product  Requirements.  A  metaprogramming  notation  can  describe  text 
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substitution,  conditional  indusion,  and  iteration  over  repetitive  decisions. 
Examine  TyE222r\  illustrates  a  fragment  of  a  Product  R^uirements  ftv  a 
DOD-STD-2167A  System/S^jnent  Specification  document  work  product  family 
of  the  TLC  domain.  This  fragment  depcts  a  pcMlkHi  oi  the  concept  (e.g.,  the 
objectives)  and  content  (e.g.,  topics)  covered  in  this  document  This  fragment  also 
defMcts  the  use  of  parameterization  (in  terms  of  apprt^xiate  dedskms  from  the 
work  product  family’s  Decision  Model  shown  in  Examine  DE.12.1-1)  to  express 
requirements  that  characterize  particular  members  of  the  wm’k  product  family. 
For  examine,  the  block  of  text  describing  the  pedestrian  lane  push-buttcm  device 
topic  is  only  included  in  the  Product  Requirements  wfren  there  is  at  least  one 
Street  in  the  ILC  system  wMdi  has  that  device. 


1.  Overview 

The  objectives  of  a  System/Segment  Specification  (SSS)  within  the  ILC  domain  are  as  fc^ows: 

•  The  SSS  specifies  the  requirements  for  a  system  or  a  segment  of  a  system  within  the  domain. 

•  The  SSS  provides  a  general  overview  of  the  ILC  system  or  segment. 


2.  Key  Topics  and/or  Functions 

The  basic  requirements  for  an  SSS  are  stated  in  the  DID  DI-CMAN-80008A.  The  members  of  the  SSS  work  product 
family  of  the  TLC  domain  vary  firom  or  interpret  this  spedfication  as  indicated  below. 


<  if  there  is  least  one  Street  S  that  has  S.Pedestrian_Lane.Push_Bntton_Mechanism  —  yes  then> 

The  SSS  shall  identify  the  push-button  device  as  an  external  to  which  the  TLC  system  must  interface.  It  shall  define  in 
detail  the  specific  interface  to  the  pudi  button  fitan  the  ILC  system  based  upon  the 
<TLC_SSS.HW_Platfomi.Interface>  interface. 

<endif> 


<if  TLC_SSS.HW_Platfonn.Platform  is  TLCl  then> 

The  SSS  shall  contain  the  subparagraph  titled  Tone  products  and  formulations  (numbered  33.1.1)  q>edfying  the 
requirements  for  the  control  of  the  toodc  products  used  in  the  manufacture  of  the  <Platform>  {datfiams. 

<endif> 


<if  TLC_SSS.HW_Platfomi.Platrorm  is  TLC2  or  TLC3  tlien> 

The  SSS  shall  omit  the  subparagraph  titled  TmdcproductsandformulaSoru  (numbered  33.1.1)  with  the  statement  "This 
subparagraph  is  not  applicable  to  this  system.” 

<cndif> 


Example  DE.23.2-1.  fragment  of  TLC  Product  Requirements  for  the  System/Segment  Spedficatkm  Work  I^oduct  Fsmily 
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•  All  inqdidt  requirements  must  be  an  elaboration  of  one  or  mwe 
oommc^ity  assumptions. 

•  The  Product  Requirments  must  elaborate  all  commonality  assumptions 
that  are  apfdicable  to  the  work  product  family. 

•  Ifdecisi<ms  that  characterize  a  particular  work  product  are  api^ed  to  the 
Product  Requirements,  the  result  should  be  a  correct  desoiption  of  that 
workivoduct 

•  One  adaptation  of  the  Product  Requirements  must  describe  a  work 
product  diat  is  relevant  to  the  targeted  project. 


3.  PROCESS  DESCRIPTION 

The  Product  Requirements  Activity  consists  of  four  steps  shown  in  Figure  DE222-1. 


to 

Product  Des^  Product  Implementation, 
Domain  Vet^icadan 


Hgure  DE.2.2.2>1.  Product  Requirements  ftooess 


3.1  Procedure 

Follow  these  steps  for  the  Product  Requirements  Activity. 

Step:  Define  the  Concept 

Action  Describe  overall  purpose  and  objectives  for  the  work  product  family. 

Input  •  Domain  Definition 

•  Decision  Model 

Result  Product  Requirements:  Cont^ept 


Opp^ 


Heuristics  •  Select  a  requirements  method  that  best  suppwts  an  abstract  description 

of  the  work  product  family.  For  documents,  a  brief  textual  descriptkm  may 
suffice. 

•  Describe  the  work  product’s  objectives  and  provide  an  overview  oi  its 
content. 


•  Examine  commonality  assumptions  to  identify  additional  aspects  of 
concepts  that  aj^ly  to  all  members  of  the  woric  (voduct  family. 

•  Examine  variability  assumptions  to  derive  additional  aspects  oi  concepts 
that  distinguish  particular  members  of  the  work  product  family.  Capture 
these  requirements  by  parameteriziqg  ccmcept  descripdcms  in  terms  oi  the 
appropriate  decisions  from  the  work  product  family’s  Dedrion  Model. 

•  Examine  Legacy  Products  from  the  Domain  Definition  to  derive 
additional  concept  requirements  that  apply  to  all  or  some  members  of  the 
work  product  family.  Describe  variations  in  concepts  in  terms  of  decisions 
in  the  work  product  family’s  Decision  Model.  If  no  such  decisions  exist, 
then  decide  whether  you  want  to  extend  the  Decision  Model  to 
accommodate  these  requirements  variations. 

Step:  Describe  the  Context 


Action 


Input 


Result 


Heuristics 


Desaibe  the  relevant  environment  and  relationships  for  the  work  product 

family. 

•  Domain  Definition 

•  Decision  Model 

Product  Requirements;  Context 

•  Desa:ibe  the  work  product’s  audience,  its  expected  benefits,  and  its 
relation  to  other  work  products. 

•  Examine  commonality  assumptions  to  derive  additional  contort 
requirements  that  appfy  to  all  members  of  the  wwk  product  family. 

•  Examine  variability  assumptions  to  derive  additional  context 
requirements  that  characterize  a  particular  member  of  the  work  product 
family.  Capture  these  requirements  by  parameterizing  contoct  descrip¬ 
tions  in  terms  of  the  aj^ropriate  dedsions  from  the  work  product  famil/s 
Dedsion  Model. 

•  Examine  Legaty  Products  to  derive  additional  context  requirements  that 
apply  to  all  or  some  members  of  the  work  product  family.  Describe  varia¬ 
tions  in  context  in  terms  of  dedsions  in  the  work  product  family’s  Dedsion 
Model.  If  no  such  dedsions  exist,  then  dedde  whether  you  want  to  extend 
the  Dedsion  Model  to  accommodate  these  requirements  variations. 


Step:  Darire  tiM  CMlMit 


AeHoH  Describe  the  subject  matt^  covered  in  ttewc>rk  product  temily. 

Ap«r  •  D(»nain  Definition 

•  Decision  hfodel 

Andr  Product  Requirements:  C(xitent 

EeuHstks  •  Describe  the  topics  covered  the  wwk  product. 

•  Bmmine  commonality  assumptions  to  derive  requirements  that  aj^y  to 
all  members  of  the  wm-k  product  family. 

•  Examine  variability  assumptions  to  derive  additional  requirements  that 
diaracterize  particular  members  of  the  wm-k  product  family.  CaiAure 
these  requirements  in  the  Product  Requirements  by  parameterizing  con¬ 
tent  des^ptions  in  terms  of  the  aj^opriate  decisions  from  the  work 
product  family’s  Decision  Model. 

•  Examine  Lega<ty  Products  of  the  Domain  Definition  to  identify  and  extract 
additional  common  and  varying  requirements  for  content  Describe  varia¬ 
tions  in  content  in  terms  of  decisions  in  the  work  |voduct  family’s  Decision 
Model.  If  no  such  decisions  exist  then  decide  n^ether  you  want  to  extend 
the  Decision  Model  to  accommodate  these  requirements  variations. 


Step:  Identify  Constraints 


Action 

bqna 


Result 

Heuristics 


Describe  limits  and  demands  on  members  of  the  work  jH’oduct  family. 

•  Domain  Definition 

•  Dedsion  Model 

Product  Requirements:  Constraints 

•  Describe  any  formatting  guidelines  or  other  restrictions  on  the  wm'k 
{MToduct 

•  Examine  commonality  assumptions  to  derive  additional  constraints  foat 
apidy  to  all  members  of  the  work  product  family. 

•  Examine  variability  assumptions  to  derive  additional  ccmstraints  that 
diaracterize  particular  members  of  the  work  fvoduct  family.  Capture 
these  requirements  by  parameterizing  constraint  descriptions  in  terms  o( 
the  apin-opriate  dedsions  fr(»n  the  work  {voduct  famify’s  Decision  Model. 

•  Examine  Legacy  Products  to  derive  additional  constraints  that  appfy  to  an 
or  some  members  oi  the  work  product  family.  Describe  variations  in 
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ooDstraints  in  terms  of  dedsicnu  in  the  work  product  Cunily's  Dectsitm 
Model.  If  no  sudi  dectsitms  exist,  then  dnade  v^ether  you  want  tt>  extend 
the  Decision  Model  to  accommodate  these  requirements  variatkms. 


3.2  Risk  Mahagement 

Bide  Product  Requirements  do  not  capture  all  Domain  Assumptiems  Mcurately. 

SmpUcatioH  A  derived  requirements  specification  will  not  accurately  describe  the  proUem 

that  the  corresponding  work  product  family  member  solves. 

ABtigation  Create  an  Application  Model  for  one  or  more  existing  work  products  and 

derive  their  respective  requirements  specifications.  Review  the  specification 
with  customers,  e3q)erienced  engineers,  and  dtmiain  experts  to  identify  any 
inaccurades. 

4.  IbTlERACTIONSimHOTlffiRACTIVrnES 

4.1  Feedback  TO  Information  Sources 

Contii^ency 

Soune 

Besponse 

Contingency 

Soune 

Besponse 

Contingency 

Soune 

Besponse 


The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Domain  Definition  Activify 

Describe  the  inadequades  in  the  Domain  Definition.  Proceed  with  Product 
Requirements,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Domain  ^finition. 

The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Domain  Management  Activify 

Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  available 
capabilities.  Complete  Product  Requirements  that  satisfy  the  Domain  Plan  as 
dosely  as  possible. 

The  practices  and  procedures  specified  in  the  Domain  Han  are  either 
ineffective  or  ineffident. 

Domain  Management  Activify 

Describe  the  ways  in  ^di  the  practices  and  {xrocedures  are  either  infective 
or  inefGdent  Propose  revisions  to  the  fxractices  and  procedures  that  will  make 
them  more  effective. 


Contingauy  The  Dedsion  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Soune  Dedsion  Model  Activify 

Besponse  Describe  the  inadequades  in  the  Dedsion  Model.  Proceed  with  Product 

Requirements,  and  document  aify  assumptions  made  regarding  the 
inadequate  portions  of  the  Dedsion  Model. 
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CoHtiiigaiey 

Soiav€ 

Rispoiise 

Contingency 

Source 

Re^nse 


n-oduct  Requirenirats  ful  to  describe  a  wwk  product  £uiiUy  that  is  oon^tent 
with  the  Dtmuun  DdinitkHL 

Domain  Management  Activity 

Modify  the  Product  Requirements  to  be  consistent  with  the  Dtmuun 
Definition. 

Product  Requirements  are  incomi^ete,  ambiguous,  or  inconsistent 

•  Product  Design  Activity 

•  Product  Implementation  Activity 

Refine  the  Product  Requirements  to  correct  inadequacies. 


DE^.2  J.  PROCESS  REQUIREMENTS  ACnVITY 

1.  GETTING  STARTED 

The  Process  Requirements  Activity  is  an  activity  of  the  Domain  Specification  Activity  for  aeating 
Process  Requirements.  Process  Requirements  is  a  description  of  the  Apjdication  Engineering  process 
currently  in  use  by  projects  in  your  organization  (including  the  targeted  project).  The  description  of 
the  process  identifies  the  activities,  work  {M'oducts,  and  common  methods  or  practices  used  ^  those 
projects  to  produce  software  work  products.  In  the  Process  Requirements  i^vity,  you  determine 
whidi  types  of  work  products  are  fvoduced,  what  steps  engineers  take  to  produce  them,  and  how  those 
steps  can  be  modified  to  allow  for  reuse. 

In  an  opportunistic  Synthesis  process  such  as  this  one,  the  goal  of  the  Process  Requirements  Activity 
is  primarily  to  document  the  actual  process  in  use  by  targeted  projects.  Any  changes  to  that  process 
intended  to  facilitate  reuse  are  minimized,  with  an  ideal  of  not  dianging  major  activities,  relationships, 
or  work  products.  Changes  are  limited  to  the  way  in  individual  work  jn’oducts  are  produced,  with 

the  intent  of  aiding  the  efficient  discovery  and  exploitation  of  opportunities  for  cost-effective  reuse. 

1.1  Objectives 

The  objective  of  the  Process  Requirements  Activity  is  to  diaracterize  the  prevalent  Ap{dication 
Engineering  process  used  by  projects  in  a  domain  and  the  work  products  that  result  It  is  assumed  that 
the  targeted  project  will  follow  a  similar  process  and  produce  work  products  of  the  same  types.  Based 
on  that  characterization,  the  Process  Requirements  Activity  identifies  which  wcrk  products  the 
targeted  project  can  likely  produce  more  easily  if  reusable  assets  are  available. 

1.2  Required  Information 

The  Process  Requirements  Activity  requires  the  Domain  Definition. 

13  Required  Knowledge  AND  Experience 

The  Process  Requirements  Activity  requires  domain  and  software  knowledge  and  «q)erience  in: 

•  The  conventional  life-cycle  process  of  systems  in  the  domain  and  the  role  of  customers  and 
standards  in  that  process 

•  How  each  of  the  work  products  of  Application  Engineering  is  produced  currently  and  how  it 
would  be  produced  if  reuse  were  a  viable  option 

2.  PRODUCT  DESCRIPTION 

Ntane  Process  Requirements 


Opp^ 


Purp^ 


Process  RequireoMots  are  an  analyrisctf  dteoffreot  ApplkaticMiEiigMieeriQg 
process  that  identifies  produmwh^  provkte  a  foci»  for  reuse 
The  {wocess  described  in  the  Process  Requirement  may  be  manual  or  may 
incorporate  varying  levels  of  autmnation. 

Content  The  Process  Requirements  wmrk  product  consists  of: 

•  Process  Spee^ketUm.  Adefiniticm  of  the  work  {M’oducts,  activities,  and 
contributing  methods  or  practices  that  af^cation  engineers  ciurently 
use.  For  eadi  activity.  Process  Specification  describes  its  purpose,  the 
work  products  created,  and  interactions  with  other  activities. 

•  Work  Product  Creation  Procedure,  A  description  of  how  ap^cation 
engineers  {x-oduce  a  work  product  either  with  or  without  reuse. 

Form  and  A  Process  Specification  can  be  described  informally  or  using  a  process 

Structure  modeling  notation.  The  form  and  content  of  each  work  in-oduct  should  be 

described  explicitly  or  by  reference  to  customer  or  industry  standards.  Section 
AE  provides  an  example  of  how  a  Work  Product  Creation  Procedure  might  be 
described. 

Verification  The  described  implication  Engineering  process  should  accurately  account  for 

Criteria  current  work  products  and  practices  of  apjdication  engineering  projects. 

3.  PROCESS  DESCRIPTION 

The  Process  Requirements  Activity  consists  of  two  steps  shown  in  Hgure  DE.2.23<1. 

3.1  Procedure 

Follow  these  steps  for  the  Process  Requirements  Activity. 

Step:  Describe  the  Application  Engineering  Process 

Action  Describe  the  process  that  application  engineering  projects  follow  to  create  an 

application  product  and  its  constituent  work  products. 

Input  Domain  Definition 

Readt  Process  Specification 

Heuristics  •  Identify  the  deliverables  that  the  Application  Engineering  |vocess  i»o- 

duces.  This  set  of  work  jvoducts  is  determined  by  the  needs  of  customers 
for  the  targeted  project  The  form  and  content  of  some  work  products  may 
be  based  on  corporate,  customer,  or  industry  standards,  as  af^ofviate. 
Work  products  that  must  satisfy  a  form  and  content  standard  are  more 
likely  to  offer  opponiinities  for  reuse. 

•  Identify  additional  (i.e.,  intermediate  or  auxiliary)  work  fvoducts  that 
result  from  the  Af^lication  Engineering  jnocess.  These  work  products 
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Figure  DE^JZJ'l.  Process  Requirements  Rooess 

retain  preliminary  or  supporting  infonnatkm  or  siqppmt  projea  and  process 
management,  including  risk  management  and  quantitative  and  qualitative 
analyses  of  deliverable  wodc  products  and  of  the  production  process. 

Step:  Formulate  a  Procedure  for  Reuse-Based  Creation  of  Worir  Products 

Action  Formulate  a  procedure  that  will  serve  as  an  informal  guide  for  aj^lication 

engineers  to  create  a  work  product,  allowing  for  discovery  and  exploitation  of 
supported  reuse  opportunities  as  appropriate. 

Lipta  Process  Specification 

Result  Work  Product  Creation  Procedure 

Heuristics  •  Start  with  an  approximate  desoription  of  the  steps  of  work  product 

creation  as  application  engineas  currentfywork.  Section  AE  {vovides  an 
ocampie  of  such  a  work  product  aeation  {vocedure.  Ai^  work  product  can 
be  aeated,  with  or  wittout  reuse,  rougl^  following  that  {xrocedure. 

•  Consider  howyourworkproductcreationprocedurewillbeafifectedbythe 
availability  of  relevant  reu^le  assets.  Provide  guidance  on  how  reuse 
should  affect  the  way  activities  are  performed.  Consider  the  guidance 
given  for  the  procedure  in  Section  AE  as  a  starting  point. 
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Risk  Management 


Risk  The  documented  Application  Engineering  process  does  not  match  actual 

practices. 

Implication  Subsequently  developed  work  product  families  will  not  suf^rt  the  creation 

of  work  products  that  projects  need  to  produce. 

Miration  Review  the  process  with  operienced  project  managers  and  engineers  to 

ensure  that  it  encompasses  all  activities  required  of  a  projet^  those  work 
products  that  customers  require,  and  those  additional  work  {voducts  that 
benefit  a  project.  Variations  in  project  needs  must  be  anticipated  and 
supported. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Domain  Definition  conflicts  with  the  Domain  Plan  or  is  incomplete, 

ambiguous,  or  inconsistent. 

Source  •  Domain  Definition  Activity 

•  Domain  Management  Activity 

Response  Describe  the  inadequacies  in  the  Domain  Definition  (e.g.,  a  targeted  {x-oject 

vhose  needs  seem  to  conflia  with  the  domain  scope).  Proceed  with  Process 
Requirements,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Domain  Definition. 

Contingency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  whidi  the  practices  and  procedures  are  either  ineffective 

or  inefficient.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingaicy  The  Process  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Process  Support  Development  Activity 

Refine  the  Process  Requirements  to  correct  inadequacies. 

The  documented  ^plication  Engineering  process  identifies  types  of  work 
products  that  do  not  correspond  to  the  needs  of  a  particular  project 


Response 

Contingency 
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Source  Project  Support  Activity 

Response  Include  in  the  Process  Requirements  any  activities  and  associated  work 

products  that  offer  an  opportunity  for  reuse  but  have  not  been  identified  as 
such  previously.  Omit  any  that  no  longer  correspond  to  accepted  practice. 
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DE^.2.4.  PRODUCT  DESIGN  ACTIVITY 


1.  GETTING  STARTED 

The  Product  Design  Activity  is  an  activity  of  the  Domain  Specification  Activity  for  creating  a  Produa 
Design.  A  Product  Design  specifies  the  design  for  work  product  family,  rather  than  for  a  single  work 
product.  A  design  describes  a  work  product  that  solves  a  specified  problem.  Similarly,  a  Product  De¬ 
sign  is  a  design  that  varies  according  to  the  dedsions  supported  by  the  work  produa  family’s  Decision 
Model.  By  applying  the  decisions  that  charaaerize  a  particular  work  produa  to  the  Produa  Design, 
a  standardized  design  of  that  work  produa  is  produced.  The  Produa  Design  Activity  is  performed  for 
each  work  produa  family  in  the  domain. 

1.1  OsjEcnvES 

The  objective  of  the  Produa  Design  Activity  is  to  aeate  a  design  for  a  work  produa  family.  The  work 
produa  family’s  design  must  satisfy  its  Produa  Requirements  and  must  be  adaptable  to  the  decisions 
allowed  by  the  family’s  Decision  Model. 

1.2  Required  Information 

The  Product  Design  Aaivity  requires  the  following  information: 

•  Decision  Model 

•  Produa  Requirements 

•  Legacy  Produas 

U  Required  Knowledge  AND  Experience 

The  Product  Design  Aaivity  requires  domain  and  software  knowledge  and  oqperience  in: 

•  The  principles  and  use  of  appropriate  design  method(s)  used  to  construa  existing  work 
products  in  the  domain 

•  How  artifacts  that  represent  domain  knowledge  (e.g.,  code,  documentation,  test  plans)  are 
designed,  including  an  appreciation  of  typical  engineering  tradeoffs  to  be  resolved 

•  The  concepts  and  practice  of  abstraction-based  reuse  (Parnas  1976;  Campbell  1989) 

2.  PRODUCT  DESCRIPTION 

Name  Produa  Design 
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Fwptae 

Coitiaa 


Vacation 

Criteria 


A  Product  Design  spedfies  the  design  oi  nrembers  oi  a  wcm-Ic  product  Cunity. 

The  Product  Design  consists  the  following  parts  for  each  work  {voduct 

family: 

•  Product  Architecture.  A  (possiUy  partial)  specification  of  the  internal 
organization  of  each  application  engineering  work  produa  that  can  be 
produced  for  the  family  (see  Section  DE2.2.4.1). 

•  Component  Desiffi.  A  spedfication  of  the  design  of  a  set  of  Adaptable 
Components  that  can  be  adapted  to  compose  draft  af^lication  engi¬ 
neering  work  products  useftil  for  the  targeted  project  (see  Section 
DE^.2.4.2). 

•  Cmeration  Design.  A  specification  of  how  a  work  product  family's 
Application  Model  is  used  to  select,  adapt,  and  compose  Adaptable 
Components  to  aeate  work  products  that  satisfy  the  Product 
Requirements  and  Product  Ardiitecture  (see  Section  DE.2.2.43). 

•  All  aspects  of  Product  Requirements  for  a  work  product  family  are 
traceable  into  the  Product  Design  for  that  family.  All  variations  in  Product 
Requirements  for  a  work  product  family  have  equivalent  variations  in  the 
Product  Design. 

•  The  Product  Design  satisfies  the  verification  criteria  appropriate  to  the 
spedfic  design  method  used  in  creating  it. 


3.  PROCESS  DESCRIPTION 

The  Product  Design  Activity  consists  of  the  three  steps  shown  in  Figure  DE.2.2.4-1. 


3.1  Procedure 

Follow  these  steps  for  the  Product  Design  Activity. 
Step:  Product  Architecture  Activity 


Action 

Input 


Result 


Create  design  structures  that  characterize  the  internal  organization  of 
members  of  the  work  product  family. 

•  Product  Requirements 

•  Legaty  Products 
Product  Architecture 


Heuristics  •  Create  multiple  design  structures  (each  portraying  a  different 

perspective)  for  a  given  work  product  family. 

•  Ensure  that  the  work  product  family's  Product  Architecture  applies  to  all 
members  of  that  family. 
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to 

Product  In^Umaita6on,Pnc»ssSi^oitDtvdopmatt, 
and 

»  Oneworkproductconvonent  DonudnVMPcatton 

per  wak  product  funily 

2  Activities  repeated  for  eadi 
work  product  family 

^  A  set  of  Component  Designs 
per  w»k  product  family 

Rgure  DE.2J2.4-1.  Roduct  Design  IVooess 
Step:  Component  Design  Activity 

Action  Create  a  Component  Design  for  eadi  of  a  set  of  Adaptable  Components  that 

compose  a  work  product  family  as  identified  by  the  ^oduct  Architecture. 

Input  •  Product  Requirements 

«  Product  Ardiitecture 

•  Lega<7  Products 

RboiU  Component  Design 

Heuristics  Ensure  that  each  Component  Design  satisfies  relevant  aspects  of  the  Product 

Architecture  and  Product  Requirements. 
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itdiM  Spedfy  a  precise  procedure  of  how  ineiid>ers  of  a  work  product  fiuaily  are 

derived  from  Adaptable  Components  based  on  the  deciskNU  in  an  Applkatkn 
Model. 

/ajpitr  •  Decision  Model 

•  Product  Ardiitecture 

•  Component  Designs 

RtsuU  Generation  Design 

Heuristics  •  Decide  how  the  decisions  for  a  work  product  family  determine  the  fmrm 

and  content  of  an  initial  draft  of  an  a[^cation  engineering  work  product. 

•  Spedfy  the  design  by  describing  how  Adaptable  Components  are  selected, 
adapted,  and  composed  according  to  the  dedsions  in  the  product  family’s 
Decision  Model. 

3.2  Risk  Management 
None 

4.  INTERACTIONS  WITH  OTHER  ACnVITffiS 
4.1  Feedback  TO  Information  Sources 

Condngency  The  Decision  Model  for  work  product  family  is  incomplete,  ambiguous,  or 

inconsistent. 

Source  Decision  Model  Activity 

Response  DesCTibe  the  inadequades  in  the  Dedsion  Model.  Proceed  with  Product 

Design,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Dedsion  Model. 

Confyigency  The  Product  Requirements  for  a  work  product  famify  are  incom[dete, 

ambiguous,  or  inconsistent. 

Source  Product  Requirements  Adivi^ 

Response  Describe  the  inadequades  in  the  Product  Requirements.  Proceed  with 

Product  Design,  and  document  ai^  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  tedinical  capabilities. 

Source  Domain  Management  Activity 
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capatnlities.  Complete  a  Prodw^  Design  that  satisfies  the  Domain  Plan  as 
dosely  as  possible. 

OmtiHgmey  The  practices  and  procedures  specified  in  the  Domain  Plan  are  eitho* 

ineffective  or  ineffident. 

Stmce  Domain  Management  Activity 

Respoiue  Describe  the  ways  in  udiich  the  practices  and  procedures  are  dtherin^fective 

or  ineffident  Propose  revisions  to  the  practices  aiKl  i^ocedures  to  make  them 
mcM'e  effective. 

4.2  Feedback  From  Product  Cor^iJMEits 

Contwgmcy  Suggestions  are  made  for  Product  Design  changes  to  oqdoit  unforeseen 

opportunities,  e.g.,  a  situation  v^ere  substantial  software  is  made  available  for 
use  in  the  Domain  Implementation  that  was  not  available  when  the  Domain 
Specification  was  com^deted. 

Source  •  Product  Implementation  Activity 

•  Process  Support  Development  Activity 

Rc^me  •  Revise  the  Product  Design. 

•  Refer  to  Domain  Mant^ement  for  future  planning. 

•  Reject  the  dianges  due  to  conflicts  with  the  Domain  Definition. 

Contii^eney  The  Product  Design  for  a  work  product  family  does  not  satisfy  the  Product 

Requirements. 

Source  Domain  Verification  Activity 

Response  Modify  the  Product  Design  to  be  consistent  with  the  Product  Requirements. 

Comingeiicy  The  Product  Design  for  a  work  jMroduct  family  is  incom{dete,  ambiguous,  or 

inconsistent 

Smarce  Product  Implementation  Activity 

Refuse  Refine  the  Product  Design  to  correct  inadequades. 
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D£.2^.4.1.  PRODUCT  ARCfflTECTlJREACnVlTY 


1.  GETTING  STARTED 

The  Product  Ardiitecture  Activi^  is  an  activity  of  the  Product  Design  Activity  for  aeating  a  Product 
Ardiitecture.  This  activity  is  performed  ftH- each  work  product  family  in  the  dcHnain.  An  ardiitecture, 
for  a  given  work  product,  is  one  or  nwre  design  structures  that  define  the  internal  organizatimi  oi  that 
work  product  from  different  perspectives.  Similarly,  a  Product  Architecture  is  a  descrij^n  the  in¬ 
ternal  organizatitm  of  a  work  product  family.  A  Product  Architecture  indudes  the  architecture  of  eadi 
of  the  work  product  families  that  make  up  the  product  family  A  Produa  Ardiitecture  varies  acoordii^ 
to  the  decisions  supported  by  the  work  product  family’s  Decision  Model.  A  Product  Architecture  de- 
saibes  a  standardi^  architecture  for  all  members  of  a  work  product  family  in  a  domain.  By  allying 
the  dedsions  that  characterize  a  particular  work  product  to  the  Product  Architecture,  a  suuxlardized 
architecture  of  that  work  product  is  produced. 

For  eadi  work  product  family  (requirements,  design,  code,  etc.),  one  design  structure  must  identify 
a  set  of  Adaptable  Components,  .^iplication  engineers  compose  instances  ctf  these  components  to 
aeate  a  draft  work  {voduct.  Depending  on  idiich  design  method  domain  engineer’s  follow,  they  may 
also  create  other  structures  whi^  {vovide  other  views  of  the  behavior  or  interrelationships  of  compo¬ 
nents.  In  all  cases,  the  structures  are  in  an  adaptable  form  so  that  Api^ication  Engineering  can  use 
them  to  produce  any  member  of  the  indicated  product  frunily. 

1.1  Objectives 

The  objective  of  the  Product  Architecture  Activity  is  to  define  an  adaptable  ardiitecture  for  a  spedfic 
work  product  family.  Product  Architecture  is  the  design  of  solutions  to  the  problems  that  Product 
Requirements  describe. 

^il^ication  engineers  create  work  products  Ity  selrating,  adapting,  and  composing  instances  of 
Adaptable  Components  that  Domain  Engineering  [voduces.  During  Product  Architecture,  domain 
engineers  identify  the  structure  of  eadi  af^cadon  engineering  work  {voduct  family  in  terms  of 
components  that  application  engineer’s  may  produce  manually  or  from  Adaptable  Components. 

12  Required  Information 

The  Product  Ardiitecture  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Legatty  Products 

U  Required  Knowledge  AND  Experience 

The  Product  Architecture  Activity  requires  domain  and  software  knowledge  and  experience  in: 
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•  Tliepriiid(^a]iduse<tfthedesigiimetbodii8edtoae«teiiianbm(tfdiework(ioductfiniii)^ 
(e.g.,  ADAPTS  [Software  Productivity  Consortium  1991]) 

•  How  systems  in  the  domain  are  designed  and  documented  following  chuen  deagn  and 
documentation  methods 

•  The  concepts  and  {M’actice  of  metai^Ogramming  (Campbell  1989) 

2.  PRODUCT  DESCRIPTION 
Name  Product  Architecture 

Purpose  The  Product  Architecture  describe  the  internal  organization  of  membm  of 

the  api^cation  engineering  work  jivoduct  family. 

Corueat  The  Product  Architecture  consists  of  design  structures  for  foe  application  work 

product  family.  One  d  foe  structures  must  identify  the  components  foat  make  up 
each  d  foe  menfoers  of  foe  work  product  famify.  Each  structure  consists  o£ 

•  A  set  of  design  elements 

•  A  relation  that  associates  elements 

For  examine,  a  software  requirements  specification  document  is  one  type  of 
application  engineering  work  product.  The  domain  engineers  might  choose 
sections  of  requirements  documents  as  design  elements,  and  “subsection**  as 
the  relation  among  these  elements.  This  describes  the  structure  of  a  software 
requirements  specification  document  in  enough  det^  to  allow  its  composition 
from  its  constituent  elements.  The  structures  developed  for  a  particular 
domain  depend  on  the  {Articular  application  work  products  and  the  design 
method  us^  to  ju’oduce  them. 

Although  the  Product  Ardiitecture  for  a  particular  work  product  may  contain 
multiple  design  structures,  there  must  be  one  structure  that  describes  the 
decomposition  of  the  work  product  into  work  assignments  (e.g.,  modules, 
sections).  The  elements  of  this  structure  corre^nd  to  components  that  are 
to  be  implemented  by  Adaptable  Components. 

The  onfy  difoenoe  between  foe  design  structures  qxdfled  in  foe  Ikoduct 
Architecture  and  foose  spedSed  in  a  omventional  de^  is  foat  foe  Product 
Architecture  is  partuneterized  and  adaptable,  so  foat  it  desoibes  foe  fanufy  (tfwoik 
products  in  foe  domain. 

The  form  for  each  structure  of  a  Product  Ardiitecture  is  a  textual  or  graffoic 
network  of  elements  and  relations.  This  rejvesentation  is  then  augmented 
with  asuitable  tedmology  such  as  metaprogramming notation  to  parameterize 
the  structure  for  adaptation  to  variations. 

Exam{de  DE.2.2.4.1-1  illustrates  a  fragment  of  a  Product  Architecture  for  a 
DOD-STD-2167A  System/Segment  Specification  document  work  [urodua 
fondfy(tf  foe  IlX^domrin.  The  Product  Architecture  of  fob  docunoent  work  product 
famify  b  aqptessed  as  an  annotated  oudine  vfoere  each  manbered  heading  (eg.,  1. 


Formand 

Structure 
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Scope)  oorrci^xxicb  to  a  section  oi  the  work  product  I^eoeding  the  aimotated 
outline  are  the  decisioas  (e^  ARCHj)edest^Janes)  that  parameterize  the 
annotated  oudine.  The  content  of  the  annckated  oudine  wQl  vaiy  dqaending  on 
values  chosen  for  these  dedskm  Rm- exan^e,  the  ccmtent  (^Section  varies 

for  some  fiunify  members.  In  odier  family  membm,  this  section  is  omitted. 


Instantiatioo  Pfenmeters 

ARCH_pedettrian_Ianes  one  of  (yea,  no)  {Avalueofyea  means  that  the  System/SegmentSpedficatioa 

must  indude  requirements  for  a  pedestrian  lane  without  pu^ 
buttons.  A  BO  value  means  the  must  omit  these 
requirements.) 

ARCH_pedestrian_lanes_pb  one  of  (yes,  no)  {Avalueofycs  means  that  the  System/Segment  Specification 

must  indude  requirements  for  a  pedestrian  lane  with  pudi 
buttons.  A  no  value  means  the  SSS  must  omit  these 
requirements.) 


Instantiation  Constraints 
Ncme 

System/Segment  Spedficatkm  Product  Architecture  (Annotated  Outlme) 

1.  Scope 

1.1  Identification 

The  approved  identification  number,  title,  and  abbreviation  of  the  TLC  ^stem. 

1.2  System  Overview 


<irArch_pcdestrian_Ianes  s  yes  thcn> 

3.2.1.1.1.j  Pedestrian_Lanes 

The  purpose  the  Pbdestrian  lanes  b  to  allow  the  safe  crosring  the  intersection  by  pedestrians.  Thb  capabUity, 
Fedmtrian  lanes  (ILC-PL),  presents  the  functionality  of  the  walk-don’t  walk  indicators  assndated  with  the  pedestrian 
lanes  of  an  intersection. 

<cndif> 


<if  Arch_pedestriaB_lanes_pb  s  yes  then> 

3.2.1.1.1.j  Pedestiian_Lanes_Wth_Push_Buttoos 

The  purpose  of  the  Pedestrian  lanes  vrith  push  butt<»sbto  allow  pedestrians  to  safely  cross  an  intersection.  TlibcapabQity, 
Pedestrian  lanes  with  push  buttons  (TLC-PB),  presents  the  functionality  of  the  w^-don’t  walk  indicators  aixl  the  push 
butUms  assodated  with  the  pedestrian  lanes  of  an  mtersection. 

<endlf> 


Examine  DE.2.2.4.1-1.  Fragment  <^’I1jC  Product  Ardutecture  for  the  System/Segment  Woric  IVoduct  Bunily 
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Milifeflrfwi  •  Each  Product  Ardiitecture  ttnicbire  satls&s  the  verifkadioo  criteria 

Criteria  estaUished  by  the  specific  iesign  method  used  in  its  creation. 

•  The  Product  Architecture  defines  all  structures  for  the  software  and  (^er 
work  products  required  by  the  ^;)plication  Engineering  process. 

3.  PROCESS  DESCRIPTION 

The  Product  Architecture  Actirity  consists  of  two  steps  shown  in  Figure  DE.2.2.4.1-1. 


to 

Component  Desiffi,  Generation  Desigp,  I^oduct  Implementation,  and 
Domain  Verification 


^  One  work  product  component 
per  work  prxxiuct  famfly 

^  Activities  repeated  for  each 
work  product  family 

Figure  DR2.2.4.1-1.  Product  Ardiitecture  Rrooess 

3.1  Procedure 


These  steps  are  performed  for  the  Product  Architecture  Activity. 

Step:  Identify  Work  Product  Components 

Action  Develop  a  structure  that  describes,  as  a  structured  set  of  components,  the 

internal  organization  of  the  work  products  in  the  family. 

Ir^ut  •  Product  Requirements 

•  Legacy  Products 

Residt  Product  Architecture;  Internal  Organization 

Heuristics  •  Examine  Legacy  Products  for  components  and  structural  relationships.  A 

work  product  usually  contains  structines  that  intuitively  identify 


DEA2.4.1.  Product  Architecture  Aeliwy 


components.  A  calling  hierardiy  is  an  eaon^e  {cx  code.  In  documents,  con¬ 
sider  baai^  the  stnic^e  around  tl^  taUe  of  contents,  especially  if  a  stan¬ 
dard  format  exists  in  the  domain  (see  the  following  heuristic). 

•  Let  the  design  methods  used  in  the  Lega^  Products  guide  you.  For 
examine,  qrstems  developed  using  ADARTS  indude  an  information  hid¬ 
ing  hierardiy.  Systems  developed  using  strudured  design  have  a  functional 
decon^xisition.  Docun^nts  develqied  using  DOD-STD-2167A  have  a 
{M-edefined  section  organization. 

•  The  structmes  that  result  from  Product  Architecture  establish  a  de  facto 
standard  in  your  organization  if  none  already  exists.  You  should,  therefore, 
try  to  use  standard  organizational  formats  in  the  domain,  such  as  those 
defined  by  ADARTS  or  DOD-SnrD-2167A.  Incorporate  any  formats  that 
are  relevant  to  the  targeted  project. 

•  The  decisions  that  parameterize  a  structure  are  related  to  the  Dedsion 
Model  for  the  work  product  family  of  which  the  Product  Ardiitecture 
forms  a  solution.  However,  the  Dedsion  Model  describes  the  problem 
space  of  the  work  product  family,  whereas  the  Product  Architecture  is 
assodated  with  the  solution  space  of  that  family.  To  reflect  this  difference, 
you  may  want  to  CTeate  parameters  that  are  not  in  the  Dedsion  Model. 
During  the  Generation  Design  Activity,  you  will  map  these  parameters  to 
dedsions  in  the  Dedsion  Model. 

•  One  motivation  for  aeating  a  Product  Architecture  is  to  break  down  a 
work  product  into  a  set  of  components  on  which  subsequent  Domain  Engi¬ 
neering  activities  (Component  Design,  Component  Implementation, 
Generation  Design)  can  be  performed  independently.  If  the  packaging  of 
Legacy  Products  does  not  conform  to  the  internal  organization,  create  one 
that  does. 

Step:  Develop  Other  Structures 

Action  Create  any  other  structures  required  to  define  the  Product  Architecture  fully. 

Input  •  Product  Requirements 

•  Legacy  Products 

Result  Product  Architecture:  Alternate  Structures 

Heuristics  •  The  chosen  design  method  for  software  identifies  other  required  design 

structures.  Using  ADARTS,  these  design  structures  are  the  Process 
Strudure  and  the  Dependency  Structure.  Hypertext-based  documents 
would  have  an  analogous  alternative  structure. 

•  Alternate  structures  impose  constraints  on  the  implementation  of  eadi 
component  of  the  internal  organization.  The  design  method  characterizes 
these  constraints. 
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•  Each  structure  must  supper  a  subset  of  the  same  variatkxts.  The  internal 
organization  determines  how  these  variations  affect  eadi  ornnpemem. 
Component  variations  must  account  properly  for  variations  in  relevant 
parts  of  the  alternate  structures. 

3.2  Risk  Management 

JRtsfc  The  Product  Architecture  will  not  support  all  features  or  variations  in  Product 

Requirements. 

Implication  The  Product  Architecture  is  not  a  correct  solution  to  the  Product 

Requirements. 

Mitigation  Review  the  Product  Ardiitecture  with  developers  of  the  Product 

Requirements  and  experienced  designers.  Establish  traceability  of  all 
required  features  to  elements  of  the  architecture.  Evaluate  whether  variations 
Riat  characterize  different  work  products  lead  to  proper  ardiitectural 
variations. 

4.  INTERACTIONS  WITH  OTHER  ACnvmES 

4.1  Feedback  TO  iNBoatMAnoN  Sources 

Contingency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Product  Requirements  Activity 

Response  Describe  the  inadequades  in  the  Product  Requirements.  Proceed  with 

Product  Architecture,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Product  Architecture  that  satisfies  the  Domain  Plan 
as  closely  as  possible. 

Contit^ency  The  practices  and  procedures  spedfied  in  the  Domain  Plan  are  either 

ineffective  or  ineffident 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  whidi  the  practices  and  procedures  are  either  ineffective 

or  ineffident.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Product  Ardiitecture  does  not  satisfy  the  Product  Requirements. 
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Source 

Response 

Contingency 

Source 


Respond 


Domain  Verification  Activity 

Modify  the  Product  Architecture  to  be  consistent  with  the  Product 
Requirements. 

The  Product  Architecture  is  incomplete,  ambiguous,  or  inconsistent. 

•  Product  Implementation  Activity 

•  Generation  Design  Activity 

•  Component  Design  Activify 

Refine  the  Product  Architecture  to  correct  inadequacies. 
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DE.2.2.4.2.  COMPONENT  DESIGN  ACnVITY 


1.  GETTING  STARTED 

The  Component  Design  Activity  is  an  activity  of  the  Product  Design  Activity  for  creating  a  Component 
Design,  llie  Product  Architecture  identifies  a  set  of  Adaptable  Components  that  may  be  used  to  im¬ 
plement  a  work  product  family.  A  Component  Design  is  a  design  specification  for  one  of  these  Adapt¬ 
able  Components.  Application  engineers,  using  the  Generation  Procedure,  may  adapt  and  compose 
a  set  of  these  components  to  implement  certain  work  products,  or  portions  thereof.  ^di  component 
must  be  designed  to  satisfy  relevant  aspects  of  the  Prt^uct  Requirements  and  all  design  structures  of 
the  Product  Architecture. 

1.1  Objectives 

The  objective  of  the  Component  Design  Activity  is  to  produce  a  design  for  an  Adaptable  Component 
that  satisfies  applicable  Product  Requirements  in  accordance  with  its  role  in  the  Product  Ardiitecture. 

1.2  Required  Information 

The  Component  Design  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Architecture 

•  Legaty  Products 

U  Required  Knowledge  AND  Experience 

The  Component  Design  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  How  components  of  systems  in  the  domain  are  designed 

•  The  principles  and  use  of  an  appropriate  design  method 

•  The  concepts  and  practice  of  abstraction-based  reuse  (Parnas  1976;  Campbell  1989) 

2.  PRODUCT  DESCRIPTION 

Name  Component  Design 
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Purpose 


A  Component  Dengn  is  a  s^)edfication  for  an  Adaptable  Component  dutt  can 
be  used  to  construct  a  draft  application  work  product 


Content  Each  Component  Design  rejn-esents  a  family  oi  components.  A  Component 

Design  consists  of  two  parts: 

•  Adaptation  Spee(/kation,  The  Adaptation  Specification  for  an 
Adaptable  Component  describes  the  ways  that  the  component  can  be 
tailored  via  a  set  of  parameters.  Each  parameter  has  a  name  and  type 
to  indicate  its  range  of  variations.  Constraints  identify  invalid 
combinations  of  parameter  variations. 

•  Interface  Spee(fieation.  The  Interface  Specification  describes  the 
desired  characteristics  of  the  implementation  of  the  component  The 
exact  content  of  the  interface  spedftcation  is  particular  to  the  compo¬ 
nent  type  and  the  design  method  used.  lb  describe  the  entire  family, 
the  interface  specification  is  parameterized  with  respect  to  the 
variations  in  the  Adaptation  Specification. 

Form  and  The  Adaptation  and  Interface  Specifications  each  include  textual  and  tabular 

Structure  information.  The  form  of  an  Adaptation  Specification  is  the  same  for  all  fypes 

of  components  and  includes  the  following  information: 

•  Name.  Name  of  the  Adaptable  Component. 

•  Instantiation  Parameters.  Adaptation  parameters  for  the  component, 
including  the  name,  type,  and  description  of  each  parameter. 

•  Instantiation  Constraints.  Constraints  on  the  instantiation  of  the 
Adaptable  Component  (e.g.,  constraints  on  the  legal  combination  of 
parameter  values). 

The  interface  part  of  Adaptable  Components  is  different  for  software  and 
documentation.  The  content  of  the  software  interface  is  specific  to  the  design 
method(s)  used  to  create  the  members  of  the  family.  The  following  types  of 
information  are  examples:  definitions  of  interface  programs  (names,  parame¬ 
ters,  parameter  types,  returned  values),  definitions  of  exported  types, 
descriptions  of  the  effects  of  interface  programs,  assumptions  about  the 
environment  in  whidi  the  software  is  to  be  used. 

The  interface  for  a  documentation  component  does  not  require  the  same  type 
of  detailed  information.  It  consists  of  a  brief  statement  of  the  content  of  die 
component.  It  should  provide  enough  information  to  determine  the 
importance  of  selecting  this  component  as  part  of  a  Generation  Procedure. 
Example  DE.2.2.4.2-1  illustrates  a  firagment  of  a  Component  Design  for  a 
DOD-STD-2167A  ^tem/Segment  Specification  work  product  family  of  the 
TLC  domain.  This  design  corresponds  to  one  of  the  adaptable  components 
identified  in  the  Product  Architecture  shown  in  Example  DE.2.2.4.1-1.  The 
Adaptation  Specification  defines  the  adaptation  parameters  for  this  adaptable 
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component.  The  Interface  Specification  is  parameterized,  where  appn^jriate, 
in  terms  of  these  adt^tion  parameters. 

ConqMoent  Dengn  -  Pedestrian  Land  wfth  Puih  Buttons  (HjC-PL'PB-I) 

Adaptation  %)edficatioo 
Instantiation  Psranieten 

OOMP_intei£sce  oneoffTL-AtlL-B)  {typeofinteifaoetotlieNvaQcAloo*twalk”li^ 

indicaton} 

COMP_hlinking_rate  one  of  (yes,  no)  {Ayes  value  means  the  pedestrian  lane  kxUeatocs 

have  a  variaUe  blinking  rate  capabSity.  A  BO  value 
means  they  do  not) 


Instantiation  Constraints 
None 

Interface  Spedficatkm 

This  component  contains  the  functional  requhements  for  the  pedestrian  lanes  present  at  the  intersection.  AH 
the  pede^rian  lanes  with  push  buttons  at  an  mtenection  must  satisfy  these  requirements.  The  indicators  and 
the  push  button  associated  with  the  pedestrian  lanes  of  this  inteiaectioocoofonn  to  the  <COMP^intcrfiace> 
standard. 

<lf  OOMP_blinkIngLnite  b  yes  thcB> 

The  variable  blinking  rate  for  the  pedestrian  lane  indicators  must  be  set  by  the  system. 

<endif> 


Examine  DE.2.2.4.2>1.  fragment  of  TLC  Component  Design  for  the  System/Segment  SpedBcationWoric  Product  Funify 

Verification  •  The  Component  Design  satisfies  the  verification  criteria  established  l^the 

Criteria  specific  design  method(s)  used  for  its  creation. 

•  The  CcHnpcmait  Design  satisfies  all  structures  of  the  Dxxluct  Architecture  fix’ 
the  wcxk  product  fiunily. 

•  The  value  for  eadi  parameter  in  an  Adaptation  Specification  either  is 
derivable  from  the  Decision  Model  for  the  work  product  fiunily  or  has  a 
fixed,  default  value  for  all  instances  of  the  component  family. 

3.  PROCESS  DESCRIPTION 

The  Component  Design  Activity  consists  of  two  steps  shown  in  Figure  DE.2.2.4.2-1. 

3.1  Procedure 

Follow  these  steps  for  the  Component  Design  Activity.  Domain  engineers  perform  these  steps  fix 

eadi  Adaptable  Component  defined  in  the  internal  organization  of  the  Product  Ardiitecture. 
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Hguie  DE.2^4^1.  Oxnpcxient  Design  ftocess 

Step:  DeGne  Component  Adaptation  SpeciGcation 

Action  Identify  the  variations  that  parameterize  the  Adaptable  Component,  and 

record  constraints  on  legal  combinations. 

If^na  •  Product  Architecture 

•  Product  Requirements 

•  Legacy  Products 

Reaoilt  Component  Design:  Adaptation  SpeciGcation 

Heuristics  •  Identify  components  in  the  Product  Ardiitecture  that  have  the  same  form 

in  all  instances  of  the  domain.  These  components  have  no  associated  varia¬ 
tions  (i.e.,  th^  are  not  adaptable).  You  must  still  provide  an  interface 
spedGcation,  but  you  may  omit  the  Adaptation  SpedGcation. 

•  Ecamine  Legaty  Products  to  determine  variations.  Concentrate  on 
semantic,  rather  than  syntactic,  distinctions.  However,  unless  you  are  will¬ 
ing  to  reengineer  work  products,  you  may  need  to  deGne  variations  based 
on  ^tactic  distinctions  as  well. 
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•  Detennine  necessary  component  adaptations  by  analyzii^  the  Product 
Requirements  to  see  how  the  component  must  vary  to  satisfy  relevant 
requirements.  In  practice,  you  should  try  to  use  both  approaches. 

•  Decisions  that  parameterize  components  must  derive  from,  but  need  not 
be,  the  decisions  identified  in  the  Decision  Model.  In  general,  there  is  a 
many-to-many  relation^p  between  Decision  Model  decisions  and  C(»n- 
ponent  Design  parameters.  You  may  use  vdiatever  decisions  most  natural¬ 
ly  specify  variations  among  members  of  the  family  defined  by  an 
Adaptable  Component. 

Step:  Specify  Component  InterCsce 

Action  Specify  the  requisite  properties  for  the  imfriementation  of  each  component. 

Input  •  Product  Architecture 

•  Component  Design:  Adaptation  Specification 

Result  Component  Design:  Interface  Specification 

Heuristics  The  properties  that  you  must  specify  depend  on  the  type  of  component  and  the 

design  method  used.  Parameterize  each  component  interface  with  the 
dedsions  from  the  component's  adaptation  specification  so  that  it  describes 
all  instances  of  the  component. 

3.2  Risk  Management 
None 

4.  INTERACnONS  WITH  OTHER  ACTIVITIES 
4.1  Feedback  TO  Information  Sources 

ContU^ency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent 

Source  Product  Requirements  Activify 

Response  Describe  the  inadequacies  in  the  Product  Requirements.  Proceed  with 

Component  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  available 

capabilities.  Comf^ete  a  Component  Design  that  satisfies  the  Domain  Flan  as 
dosely  as  possible. 
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ComUitmey 

Source 

Response 


Contu^eney 

Source 

Response 


The  practioes  and  procectoes  ^)ecified  in  die  Domain  Ptan  are  eitter 
infective  or  inefiEkient 

Dmnain  Management  Activity 

Describe  the  ways  in  vdiidi  the  practices  and  procedures  are  either  ineffective 
or  ineCBdent.  Propose  revisions  to  the  practices  ami  procedures  to  make  them 
more  effective. 

The  Product  Architecture  is  incomplete,  ambiguous,  or  inconsistent 
Product  Architecture  Activity 

Describe  the  inadequades  in  the  Product  Architecture.  Proceed  with 
Component  Design,  ami  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Ardiitecture. 


4.2  Feedback  From 
Contingency 


Source 


Refuse 


Contingency 

Source 

Response 

Contingency 

Source 

Response 


Product  Consumers 

Suggestions  are  made  for  Component  Design  changes  to  oqdoit  unforeseen 
opportunities.  Fbr  examine,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Elomain  Im{dementation  that  was  not  available  ^en 
the  Component  Design  was  oomfdeted. 

•  Product  Implementation  Activity 

•  Process  Support  Development  Activity 

•  Revise  the  Component  Design. 

•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

The  Component  Design  does  not  satisfy  the  Product  Requirements. 

Domain  Verification  Activity 

Modify  the  Component  Design  to  be  consistent  with  the  Product 
Requirements. 

The  Component  Design  is  incomplete,  ambiguous,  or  inconsistent 

•  Component  Implementation  Activity 

•  Generation  Design  Activity 

Refine  the  Component  Design  to  correct  inadequacies. 


DE2J2A3.  GENERATION  DESIGN  ACnVITY 


1.  GETTING  STARTED 

The  Generation  Design  Activity  is  an  activity  of  the  Product  Design  Activity  for  aeating  a  Generation 
Design.  A  Generation  Design  is  a  ^jedficatkMi  of  production  procedures  that  an  qjpikatioii  engineer  uses 
to  produce  draft  apfdication  engineering  wcvk  products.  A  Generation  Design  defines  a  transfonnatioa 
(or  mapping)  from  an  ^jpUcadon  Kfodei  to  the  equivalmt  application  engineering  work  products.  For 
each  ai^ication  engineering  work  product,  a  Genenuion  Desi^  q)ecifies  how  to  select  and  ad^  Adapt¬ 
able  Components  according  to  decisions  in  an  ^splication  Model  and  to  oranpose  tl^m  according  to  the 
internal  organization  of  that  work  product  in  the  Product  Architecture.  The  Generation  Defign  Activity 
is  performed  for  eadi  work  product  specified  by  the  Product  Requirements. 

1.1  Objectives 

The  objective  of  the  CJeneration  Design  Activity  is  to  produce  a  specification  for  the  production 
procedures  that  can  be  used  to  produce  apj^ication  engineering  work  products  for  a  member  of  a  work 
product  family  through  reuse  of  Adaptable  Components.  The  specification  establishes  a  correspon¬ 
dence  between  an  Application  Model  and  equivaloit  domain  engineering  wwk  products  that  implement 
the  intent  of  the  model  correctly. 

1.2  Required  Information 

The  Generation  Design  Activity  requires  the  following  information: 

•  Decision  Model 

•  Product  Architecture 

•  Component  Designs 

13  Required  Knowledge  AND  Experience 

The  Generation  Design  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  How  work  products  of  tystems  in  the  domain  are  designed 

•  The  principles  and  use  of  the  design  method  used  for  the  Prodwx  Ardiitecture 

•  The  concepts  and  practice  of  abstraction-based  reuse  (Pamas  1976;  Campbell  1989) 
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2.  PRODUCT  DESCRIPTION 


Name 

Purpose 

Comaa 


Form  and 
Structure 


Generatkm  Design 

A  Generation  Design  is  a  spedficatkm  for  a  production  procolure  for  aeating 
draft  ai^ication  engineering  work  products. 

A  Generation  Design  relates  the  decisions  from  the  Decision  Model  to  the 
elements  of  a  work  product's  internal  (vganization  defined  in  the  Product 
Architecture.  A  Generation  Design  consists  of  three  ma|^)ings: 

•  i4reiUi(eclitfvMi^ppiiV.TheArchitectureMapi»ngisadescriptionofthe 
relation  between  decisions  in  the  work  prodi»:t  family's  Decision  Mod' 
el  and  the  decisions  of  the  corresponding  adaptable  Product  Architec¬ 
ture.  This  ma{^[^  describes  h^  values  for  the  Product  Architec¬ 
ture's  decisions  are  determined  from  values  of  decisions  in  the 
Decision  Model.  As  a  result,  the  Ardiitecture  Mapping  defines  the  in¬ 
ternal  organization  of  a  work  jnroduct  that  describe  a  member  of  the 
work  product  family  based  on  decisions  in  the  Decision  Model  (i.e., 
from  an  Application  Model). 

•  Component  Mappii^.  A  Component  Mapping  is  a  description  of  the 
relation  of  each  element  of  the  organizational  structure  to  an  Adapt¬ 
able  Component  that  implements  that  element.  This  mapping  defines 
how  each  component  of  a  work  product  is  to  be  product. 

•  Decision  Mapping.  A  Decision  Mapping  is  a  description  of  the  relation 
between  decisions  in  the  work  produa  family’s  Decision  Model  and 
the  instantiation  parameters  in  the  adaptation  specification  of  a  Com¬ 
ponent  Design  for  each  work  jn’oduct  component.  This  relation  de¬ 
scribes  how  values  for  the  instantiation  parameters  are  determined 
from  values  of  decisions  in  the  work  product  family’s  Decision  Model. 

There  is  a  Generation  Design  for  each  supported  work  product.  The 
Architecture  Mapping  is  represented  as  a  statement  for  each  instantiation 
parameter  of  the  work  product's  Product  Architecture.  The  statement 
contains  a  pairing  between  an  instantiation  parameter  and  an  expression.  The 
expression  to  determine  the  value  to  assign  an  instantiation  parameter  is 
described  in  terms  of  d^ions  in  the  work  product  family’s  Dedsion  Model. 
The  opression  may  involve  iteration  over  a  group  of  decisions  or  conditional 
testing  of  one  or  more  dedsions. 

The  Dedsion  Mapping  representation  is  similar  to  the  Ardiitecture  MapjHng, 
except  that  the  instantiation  parameters  come  from  the  adaptation 
spedfication  of  the  Component  Design  for  the  work  product. 


The  Component  Mapping  is  rejvesented  as  a  "use”  statement  If  the 
opression  bracketing  the  use  statement  is  True,  then  the  use  statement 
describes  whidi  Adaptable  Component  contains  the  needed  implementation. 
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The  opression  is  usually  described  in  terms  of  dedsions  in  the  work  product 
family’s  Decision  Model.  However,  if  the  Adaptable  Component  is  always 
used,  then  an  expression  of  Urue  is  sufBdent  to  describe  this  situation. 

Example  DE.2.2.4  J-1  illustrates  a  fragment  of  a  Generation  Design  for  a  work 
product  family  of  the  TLC  domain.  It  de{»cts  one  way  of  representing  the 
expressions  discussed  for  Architecture,  Component,  and  Dedsion  Mapping. 
The  dedsions  used  the  metaprogramming  notation  come  directly  from  the 
Dedsion  Model  shown  in  Example  DE.2.2.1-1.  The  parameters  on  the 
lefrhand  side  of  the  “ = ”  statements  in  the  Ardiitedure  and  Dedsion  Mapping 
come  from  Examples  DE.2.2.4.1-1  and  DE.2.2.4.2-1,  respectively. 


Aichitectinre  Mapping 

ARCH_pedekrian_Ianes  =  <ir  there  is  a  Street  S  that  has  a  Pedestrian^Lane  spcdfled 

and  SJPedestrian_Lane.Piish_Battoa_MechaBbai  =  no  then> 
yes 

<else> 

no 

<endif> 

ARCH_pedestrianJanes_pb  =  <if  there  is  a  Street  S  that  has  a  Pedestrian_Lane  specified 

and  S.Pedestrian_Lane.Push_Button_Mechanisni  »  yes  then> 
yes 

<eise> 

no 

<endif> 


Component  Mapping 

Reqiiired  topic:  Pedestrian_Lanes_V^th_Push_Buttons 

<if  TLC_SSS.HW_Piatform.Piatfomi  =  TLC2  then> 

use  component  Tedestrian  lanes  with  Push  Buttcms  fTLC-FL-PB*!)” 
<e]se> 

use  omnponent  Tedestrian  lanes  with  Push  Buttons  (TLC-FL>PB>2)’’ 
<endif> 


Dedsion  Mapping 

Pedestrian  lanes  with  Push  Buttons  (I1X>PL-PB>1) 

COMP  interface  =  <ifTLC  SSS.HW  PlatformJnterface  s  TL.Athcn> 
TL-A 
<elsc> 

HL-B 

<endif> 


Exanqde  DE.2.2.4J-1.  Ragment  of  TLC  Generation  E>edgn  for  the  System/Segment  Specification  Work  Product  Fsmily 
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Criteria 


•  The  Generatioa  Design  ^ledfies  mappings  diat  will  produce  applicatkm 
work  products  whidi  ezhilnt  the  internal  (nganizatkm  spectfi^  in  the 
Product  Architecture. 

•  The  Generation  Design  spedfiesma|^)ings  that  produce  applicaticMi  work 
products  which  satisfy  the  Product  R^uirements  (i.e.,  the  mappings  are 
consistent  with  Product  Requirements  variaticm). 

•  All  variabilities  allowed  by  dedsions  are  properly  represented  as  product 
variations. 

•  The  effects  of  variabilities  among  work  products  are  mutually  consistent 
(i.e.,  all  mappings  are  consistent). 


3.  PROCESS  DESCRIPTION 


The  Generation  Design  Activity  consists  of  two  steps  shown  in  Figure  DE22A3-1. 


to 

Genemdon  Implanentadonand 
Domain  Vmfiadion 


*  One  wwk  product  oompoaent 
per  work  product  family 

2  Activities  repeated  for  eadi 
work  product  family 


Figure  DE.2.2.43>1.  Generation  Design  IVocess 


3.1  Procedure 

Step:  Define  Work  Product  Structure 

Action  Define  how  decisions  in  the  Decision  Model  affect  the  structure  of  the  work 

product. 
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Inpta  •  Decision  Model 

•  Product  Architecture 

Result  Generation  Design:  Architecture  and  Component  Maj^angs 

Heuristics  •  It  is  sufficient  to  define  the  work  {MTOduct  structure  as  a  maf^ng  from  the 

Decision  Model  to  the  internal  organization  of  the  Product  Architecture 
for  the  work  product.  The  internal  organization  defines  the  components 
that  are  required  to  imi^ement  the  work  product.  This  mating  deter¬ 
mines  which  elements  of  the  Product  Architecture  are  imj^emented  for  a 
particular  i^)plication  Model. 

•  The  Product  Architecture  determines  (conditionally  and  iteratively)  how 
components  of  each  work  product  are  to  be  derived  from  Adaptable  Com¬ 
ponents  (i.e.,  the  component  mapping  is  provided  implicitly  1^  the  Product 
Architecture).  The  Generation  I^sign  should  not  modify  that  mapping. 

•  Represent  this  mapping  in  metaprogranuning  notation  associated  with 
components  in  the  Product  Architecture.  The  mapiMng  is  defined  in  terms 
of  decisions  in  the  Decision  Model  and  determines  v^diether  (one  or  more 
of)  the  associated  component(s)  should  be  included  in  the  product  created 
for  a  given  Application  Model.  This  mapping  is  formed  analyzing  the 
Product  Architecture  and  noting  conditions  that  must  be  true  if  a  particu¬ 
lar  component  is  to  be  included.  If  a  component  is  always  included  in  the 
product,  metaprogramming  notation  is  not  required. 

•  Several  Adaptable  Components  might  be  used  to  implement  a  single 
Product  Architecture  component,  depending  on  decisions  in  the  Applica¬ 
tion  Model.  In  this  case,  use  a  conditional  in  the  Component  Mapping  to 
qualify  the  association  between  the  Product  Architecture  and  Adaptable 
Q)mponents,  thus  indicating  when  a  particular  Adaptable  Component  is 
used. 

Step:  Define  Component  Adaptation 

Action  Define  a  mapping  from  the  decisions  in  the  Decision  Model  to  adaptations  of 

the  Adaptable  Components  referenced  by  the  Component  Mapping. 

Input  •  Decision  Model 

•  Component  Design 

•  Generation  Design:  Component  Mapping 

Result  Generation  Design:  Decision  Mapping 

Heuristics  When  a  particular  Component  Design  is  to  be  used  to  implement  a  particular 

component  in  the  Product  Architecture,  the  variabilify  of  the  Adaptable 

Component  (i.e.,  its  parameterization)  must  be  realized  in  terms  of  decisions 
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from  the  Deciskm  Model.  Define  the  value  of  each  parameter  (by  name)  as 
a  derivation  from  Decision  Model  decisions. 

3.2  Risk  Management 

Risk  The  Generation  Design  will  not  produce  correctly-structured  work  pi  oducts. 

Im^cation  Application  Production  will  not  produce  acceptable  api^cation  engineering 

work  products. 

Mitigation  Derive  work  product  structures  from  the  Generation  Design  for  Application 

Models  of  familiar  work  products  and  review  the  result  with  e:q)erienced 
engineers  to  determine  whether  the  result  is  acceptable. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 


Contingaicy 

Source 

Response 

Contingency 

Source 


The  Decision  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Decision  Model  Activity 

Describe  the  inadequacies  in  the  Decision  Model.  Proceed  with  Product 
Architecture  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Decision  Model. 

The  Product  Requirements  for  a  work  product  family  are  incomplete, 
ambiguous,  or  inconsistent. 

Product  Requirements  Activity 


Response 


Contingency 

Source 


Describe  the  inadequacies  in  the  Product  Requirements.  Proceed  with 
Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

The  Domain  Plan  caimot  be  satisfied  with  available  technical  capabilities. 

Domain  Management  Activi^ 


Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Generation  Design  that  satisfies  the  Domain  Plan  as 
closely  as  possible. 

Qmtingency  The  practices  and  procedures  spedfied  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 


Source  Domain  Management  Activi^ 

Response  Desaibe  the  ways  in  whidi  the  practices  and  procedures  are  either  ineffective 

or  ineffident.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 
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Contingency 

Source 

Response 

Contingency 

Source 

Response 

4.2  Feedback  From 
Contingency 

Source 

Response 

Contingency 

Source 

Response 


The  Product  Architecture  for  a  work  product  family  is  incomplete,  ambiguous, 
or  inconsistent. 

Product  Architecture  Activity 

Describe  the  inadequacies  in  the  Product  Architecture.  Proceed  with 
Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Architecture. 

The  Component  Design  for  a  work  product  family  is  incomplete,  ambiguous, 
or  inconsistent. 

Component  Design  Activity 

Describe  the  inadequacies  in  the  Component  Design.  Proceed  with 
Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Component  Design. 

Product  Consumers 

The  Generation  Design  for  a  work  product  family  does  not  satisfy  the  Product 
Requirements. 

Domain  Verification  Activity 

Modify  the  Generation  Design  to  be  consistent  with  the  Product 
Requirements. 

The  Generation  Design  for  a  work  product  family  is  incomplete,  ambiguous, 
or  inconsistent. 

Generation  Implementation  Activity 

Refine  the  Generation  Design  to  correct  inadequacies. 
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DE.23.  DOMAIN  VERIFICATION  ACnVITY 


1.  GETTING  STARTED 

Domain  Verification  is  an  activity  of  Domain  Ei^eering  for  ensuring  the  correctness,  consistencty, 
and  completeness  of  domain  engineering  work  products.  Both  formal  and  informal  techniques  may 
be  appli^  to  the  domain  engineering  work  products  to  verify  these  properties.  Domain  Verification 
is  an  independent  verification  activity  performed  separately  from,  and  in  addition  to,  the  verification 
performed  as  part  of  each  Domain  Engineering  Activity. 

The  Domain  Verification  Activity  is  motivated  Ity  the  same  concern  that  motivates  Independent 
Verification  and  Validation  (IV&V)  in  a  conventional  software  development  process;  namely,  that 
engineers  involved  in  developing  a  work  product  cannot  objectively  judge  the  quality  of  that  work 
product.  Independent  validation  of  the  domain  engineering  product,  from  the  perspective  of  client 
projects,  is  conducted  in  the  Domain  Validation  step  of  the  Reject  Support  Activity. 

Domain  Verification  establishes  the  correemess,  consistentty,  and  completeness  of  domain 
engineering  work  products.  These  terms  have  a  precise  meaning  in  the  contort  of  this  activity.  The 
concept  of  correctness  is  that  of  relative  correctness.  Similarly,  the  concept  of  completeness  is  that  of 
relative  completeness.  A  work  product  is  said  to  be  correct  (complete)  with  respect  to  some  oiteria 
or  to  a  more  abstract  representation  of  the  entity  the  work  product  describes.  For  escample,  the  Prod¬ 
uct  Implementation  for  a  work  product  family  can  be  said  to  be  correct  (complete)  with  respect  to  its 
Product  Requirements.  Consistency,  on  the  other  hand,  is  a  term  that  applies  to  a  collection  of  related 
work  products  (at  the  same  level  of  abstraction)  that  form  a  whole.  IWo  products  are  consistent  when 
they  exhibit  the  intended  interrelationships.  For  example,  the  Product  Axchitecture,  Component  De¬ 
sign,  and  Generation  Design  work  products  for  a  work  product  family  are  strongly  interrelated,  and, 
therefore,  mutual  consistency  is  an  important  property  for  these  work  products. 

1.1  Objectives 

The  objective  of  Domain  Verification  is  to  independently  evaluate  the  quality  of  domain  engineering 
work  products. 

1.2  Required  Information 

Domain  Verification  requires  the  following  information: 

•  Domain  Definition 

•  Domain  Specification 
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Domain  In^ementation 


•  Domain  Plan:  Practices  and  Procedures 
U  Required  Knowledge  AND  Experience 

The  Domain  Verification  Activity  requires  domain  and  software  knovdedge  and  e:q)erience  in: 

•  Appropriate  software  verification  techniques 

•  How  to  systematically  plan  and  perform  software  verification 

2.  PRODUCT  DESCRIPTION 

There  are  no  Synthesis  work  products  produced  during  Domain  Verification. 

3.  PROCESS  DESCRIPTION 

The  Domain  Verification  Activity  consists  of  three  steps  shown  in  Figure  DE.2.3-1. 


I^gure  DE.23>1.  Domain  Verification  Rocess 

3.1  Procedure 

Step:  Verify  Domain  Definition 

Action  Verify  the  correctness,  consistency,  and  completeness  of  the  Domain 

Defidtion. 

Irvut  •  Domain  Definition 

•  Domain  Plan:  Practices  and  PrcKedures 
Result  None 

Heuristics  •  Verify  that  the  parts  of  the  Domain  Definition  are  correct  and  complete 

with  respecx  to  the  guidance  provided  in  their  respective  activity 
descriptions. 
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•  Verify  that  the  parts  of  the  D(MiiauiD^iiution  are  correct  with  to 

any  specific  qualify  attributes  required  of  them  in  the  Practices  and 
Procedures  portion  of  the  Domain  Plan. 

•  Verify  that  the  Domain  ^nopsis.  Domain  CHossary,  and  Domain 
Assumptions  are  mutually  consistent. 

•  Use  the  verification  criteria,  established  for  the  Domain  Definition  in  its 
activity  description,  as  guidance  in  verifying  the  Domain  Definition. 

•  Use  static  analysis  tediniques  (e.g.,  formal  inspections,  reviews,  analysis 
tools)  to  verify  the  Domain  Definition.  These  techniques  are  appropriate 
because  the  Eiomain  Definition  is  typically  represented  in  document  finm. 

Step:  Verify  Domain  Specification 


Action  Verify  the  correctness,  consistency,  and  completeness  of  eadi  work  product 

family  in  the  Domain  Spedfication. 

Input  •  Domain  Definition 

•  Domain  Specification 

•  Domain  Plan;  Practices  and  Procedures 

BesuU  None 


Heuristics 


•  Perform  this  step  for  each  work  product  family  in  the  Domain 
Spedfication. 

•  Verify  that  the  parts  of  the  Domain  Spedfication  are  correct  and  complete 
with  respect  to  the  guidance  provided  in  their  respective  activity 
descriptions. 

•  Verify  that  the  parts  of  the  Domain  Specification  are  correct  with  respect 
to  any  specific  qualify  attributes  required  of  them  in  the  Practkes  and 
Proc^ures  portion  of  the  Domain  Plan. 

•  Verify  that  the  Prcxluct  Requirements  and  Product  Design  for  a  work 
product  family  are  consistent  with  its  Dedsion  Model.  This  means  that 
these  work  prcxlucts  only  reference  dedsions  in  the  Dedsion  Model  and, 
conversely,  all  applicable  dedsions  in  the  Dedsion  Mcxlel  are  reflected  in 
the  work  products. 

•  Verify  that  the  Product  Architecture,  Component  Design,  and  Generaticm 
Design  for  a  work  prcxluct  family  are  mutually  consistent. 

•  Verify  that  the  Prcxiuct  Design  for  a  work  prcxluct  family  is  correct  and 
complete  with  respect  to  its  Product  Requirements. 
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•  Verify  that  the  Process  Requirements  is  oorrea  and  oomfdete  with  re^)ect 
to  the  assumptitMis  about  the  Application  Engineering  process  in  the  Do¬ 
main  Definition.  The  Apf^kation  Engineering  process  is  normally  not 
aq>lidtly  described  in  the  Domain  Definition,  but  the  Domain  Definition 
will  tyfMcally  constrain  what  is  an  accefHable  A{^cation  Jl^igineeriqg 
process. 

•  Verify  that  the  Product  Requirements  and  Product  Design  are  correct  and 
complete  with  respect  to  the  representation  of  the  Prodmrt  Family  in  the 
Domain  Synopsis  and  Domain  Assumptions  parts  of  the  Domain 
Definition. 

•  Use  the  verification  criteria,  established  for  the  Domain  Specification 
work  products  in  their  respective  activity  descriptions,  as  guidance  in 
verifying  the  Domain  Spedfication. 

•  Use  static  analysis  techniques  (e.g.,  formal  inspections,  reviews,  analysis 
tools)  to  verify  the  Domain  Specification  for  a  work  product  family.  These 
techniques  are  aj^oj^iate  because  the  Domain  Spedficaticm  is  typicalfy  rq>- 
resented  in  document  form.  If  parts  of  the  Domain  Spedfication  are  x&ptt- 
sented  in  an  executable  form,  the  use  of  (fynamic  analysis  tedmiques  may  be 
appropriate. 

Step:  Verify  Domain  Implementation 

Action  Verify  the  correctness,  consistency,  and  completeness  of  eadi  work  produa 

family  in  the  Domain  Implementation. 

Input  *  Domain  Spedfication 

•  Domain  Implementation 

•  Domain  Plan:  Practices  and  Procedures 

Result  None 

Heuristics  •  Perform  this  step  for  eadi  work  product  family  in  the  Domain 

Implementation. 

•  Establish  the  criteria  that  you  e3q>ect  the  Domain  Implementation  to  meet 
before  you  try  to  verify  it  Identify  analysis  that  you  can  perform  that  the 
Domain  Implementation  is  correct  with  respect  to  the  Domain  Spedfica¬ 
tion.  Your  plan  should  minimally  establish  verification  objectives  and 
describe  a  strategy  for  meeting  those  objectives. 

•  Verify  that  the  parts  of  the  Domain  Implementation  are  correct  and 
complete  with  respect  to  the  guidance  provided  in  their  respective  activity 
descriptions. 

•  Verify  that  the  parts  of  the  Domain  Implementation  are  correct  with 
respect  to  any  sptK^c  qualify  attributes  required  of  them  in  the  Practices 
and  Procedures  portion  of  the  Domain  Plan. 
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•  Verify  that  the  Process  Support  and  Product  Imi^ementation  ftv  a  work 
product  family  are  mutually  ccmsistent 

•  Verify  that  the  Component  Implementation  and  the  Gennatkm 
Implementation  for  a  work  product  family  are  mutually  consistent 

•  Verify  that  the  Process  Suj^XHrt  for  a  work  product  family  is  correct  with 
respect  to  its  Process  Requirements. 

•  Verify  that  documents  and  automation  that  make  up  the  Process  Support 
are  engineered  in  a  way  that  adequately  addresses  human  factors  con¬ 
cerns.  For  examfde,  you  should  establish  that  the  Api^cation  Engineering 
Environment  portion  Process  Support  has  the  qualities  of  usability, 
adequate  performaiKe,  and  tolerance  of  user  errors. 

•  Verify  that  the  Product  Imfdementation  for  a  work  product  family  is 
correct  and  oom(dete  with  respect  to  its  Domain  Specification.  The  re¬ 
quirements  for  the  Product  Implementation  are  represented  in  the  Prod¬ 
uct  Requirements  portion  of  the  Domain  Spedfication.  The  internal  orga¬ 
nization  for  the  Product  Imfdementation  is  rejn’esented  in  the  Product 
Design  portion  of  the  Domain  Specification. 

•  Verify  that  a  work  fn'oduct  produced  using  the  Process  Support  has 
expected  properties.  Do  this  1^  resolving  the  decisions  of  the  work  product 
family’s  Decision  Model,  {M’odudng  the  work  product  corresponding  to 
that  model,  and  then  verii^ng  that  the  work  product  has  the  expected 
properties.  Spedfically: 

-  Verify  that  the  work  product  produced  by  the  Process  Support  is 
correct  and  complete  with  respect  to  the  Product  Requirements 
and  Product  Design  of  its  corresponding  work  product  family  (ap¬ 
propriately  instantiated  with  the  dedsions  from  the  Dedsion  Mod¬ 
el). 

-  Verify  the  usabilify  and  correctness  of  the  Delivery  Support.  This 
should  be  established  through  direct  inspection  and  by  using  the 
delivery  support  to  install/deliver  the  A]^lication  Product. 

A  good  strategy  for  selecting  work  products  to  produce  is  to  try  to  build  all 
or  part  of  Legaty  Products  that  are  within  the  intended  scope  of  the 
domain. 

•  Use  the  verification  oiteria,  established  for  the  Domain  Implementation 
work  products  in  their  respective  activity  descriptions,  as  guidance  in 
verifying  the  Domain  Implementation. 

•  Use  conventional  verification  tedmiques  that  are  appropriate  to  the  task 
of  verifying  the  Domain  Implementation  for  a  work  product  family.  Static 
analysis  tedmiques  (e.g.,  inspections)  are  appropriate  for  static 
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repreaentitioM  of  tbe  Domain  Iiiq)leineBimk»  (04^  ApfiBatioa 
Enginenii^  Utn  Gukk).  Dymrn^  aaiilyiis  tecbiyqiies  (04^  tettiiig)  are 
appropriate  for  dynamic  a^wcts  of  die  Domain  In^emoitmion  (e^ 
automated  suppwt  for  specification,  analy^,  and  product  generation). 


3.2  Risk  Mahagemdit 

JQUfc  The  criteria  used  to  evaluate  the  domain  engineering  work  products  will  be 

unduly  influenced  by  the  final  cratent  and  form  of  the  work  products 
themselves. 

JtofpfieadM  The  effectiveness  of  the  verification  effort  will  be  rnluced. 

iMtaikm  Define  acceptable  levels  of  correctness,  completeness,  and  consistem^  for 

each  dcHnain  engineering  work  product  prior  to  examining  it. 

4.  INTERACTIONS  WITH  OTHER  ACTIVmES 

4.1  Feeiwack  TO  Information  Sources 
The  Domain  Definition  is  incorrect,  inconsistent,  or  incomplete. 

Domain  Definition  Activity 

Precisely  communicate  how  the  Domain  Definition  is  incorrect,  inconsistent, 
or  incomplete. 

The  Domain  Spedfication  for  a  work  product  family  is  incorrect,  inconsistent, 
or  incomplete. 

Domain  Specification  Activity 

Precisely  communicate  how  the  Domain  Specification  is  incorrect, 
inconsistent,  or  incomplete. 

The  Domain  Implementation  for  a  work  product  family  is  incorrect, 
inconsistent,  incomplete. 

Domain  Implementation  Activity 

Precisely  communicate  bow  the  Domain  Implementation  is  incorrect, 
inconsistent,  or  incomplete. 

4.2  Feedback  From  Product  Consumers 
None 


Qmlinteney 

Source 

Response 

Contingency 

Source 

Re^mae 

Contingency 

Source 

Response 
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DE3.  DOMAm  IMPLEMENTATION  ACnVITY 


1.  GETTING  STARTED 

Domain  Implementation  is  an  activity  Domain  &igineering  for  implementing  product  and  {vocess 
support  for  apjriication  engineering  {vojects  in  a  business  area.  The  Domain  Imi^ementation  must 
satisfy  the  Domain  Spedfication  created  by  Domain  Analysis.  Prodia^t  sujqx^  consists  of  a  set  of  pro¬ 
duction  procedures  and  associated  Adaptable  Components  that  can  be  used  to  create  standarchzed 
members  of  a  work  product  family.  Process  support  consists  of  {vocedures,  documentation,  and, 
optionally,  automation  that  support  of^rtunistic  reuse  during  Application  Engineering.  The 
Etomain  Implementation  Activity  is  performed  for  eadi  work  product  family  in  the  domain. 

1.1  OBJECTIVES 

The  objectives  of  the  Domain  Implementation  Activity  are  to: 

•  Create  a  set  of  Adaptable  Components  and  associated  Generation  Procedures  as  specified  in 
the  Product  Design  for  the  work  product  families  dedgnated  as  relevant  to  the  targeted  project 

•  Create  standard  procedures  by  which  production  of  application  engineering  work  jM^oducts 
takes  advantage  of  provided  reuse  opportunities 

1.2  Required  Information 

The  Domain  Implementation  Activify  requires  the  following  information: 

•  Domain  Specification 

•  Legacy  Products 

13  Required  Knowledge  AND  Experience 

The  Domain  Imj^ementation  Activify  requires  domain  and  software  kno^edge  and  experience  in: 

•  Tbchnologies  for  oreating,  adapting,  and  composing  Adaptable  Components  into  work 
products  and  the  verification  of  sudi  Adaptable  Ccnnponents  and  work  jx-oducts 


Documenting  and  providing  automated  support  for  ^ijdication  Ei^eering  activities 
How  work  products  of  existing  systems  in  the  domain  are  imfdemented 
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2.  PRODUCT  DESCRIPTION 


Name 

Purpose 


Content 


Verification 

Criteria 


Domain  Implementation 

A  Domain  Implementation  contains  sets  of  Adaptable  Con^x)nents  and 
associated  production  procedures  that  you  can  use  to  create  members  of  work 
product  families  relevant  to  the  targeted  project.  The  Domain 
Implementation  also  consists  of  the  procedures,  documentation,  and, 
optionally,  automation  that  support  of^rtunistic  reuse  during  ^plication 
Engineering. 

A  Domain  Implementation  consists  of  two  components: 

•  Product  ImpUmerOation.  A  Product  Implementation  contains  organized 
implementations  of  work  product  families  (see  Section  DE3.1). 

•  Process  Support.  An  application  engineering  infrastructure  that 
supports  the  targeted  project  in  performing  opportunistic  reuse  of 
work  products  (sec  Section  DE.3.2). 

The  Domain  Implementation  supports  each  designated  work  product  family 
identified  in  the  Domain  Specification  as  prescribed  by  the  Product 
Requirements  for  that  family. 


3.  PROCESS  DESCRIPTION 

The  Domain  Implementation  Activity  consists  of  the  two  steps  shown  in  Figure  DE.3-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Implementation  Activity. 

Step:  Product  Implementation  Activity 

Action  Implement  a  work  product  family. 

Input  •  Domain  Specification 

•  Legacy  Products 

Result  Product  Implementation 

Heuristics  •  Derive  the  Product  Implementation  of  a  work  product  family  from 

appropriate  Legacy  Prcxiucts. 

•  Desca'ibe  a  mechanical  prcxxdure  by  which  application  engin'a  '  can 
select,  adapt,  and  compose  a  draft  application  work  product. 

•  Implement  only  the  portions  of  the  prcxluct  (i.e.,  members  of  the  work 
prc^uct  family)  required  for  the  targeted  project. 
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. I . 

to 

Prefect  &tf^port  and  Domain  Verification 

^  One  work  product  component 
per  work  product  family 

^  Activities  repeated  for  each 
work  product  family 

Figure  DE3-1.  Domain  Implementation  Flrocess 
Step:  Process  Support  Development  Activity 

Action  Create  an  application  engineering  infrastructure  to  support  reuse  of  existing 

application  engineering  work  products. 

Input  •  Product  Implementation 

•  Domain  Specification:  Process  Requirements 

Restdt  Process  Support 

Heuristics  •  Document  a  procedure  that  application  engineers  can  follow,  as  part  of 

their  normal  process  for  developing  a  work  product,  to  help  them  locate 
and  reuse  existing  work  products. 

•  Optionally  provide  automated  medianisms  whidi  support  the  effective 
and  correct  performance  of  the  reuse-related  activities  of  Application 
Engineering  for  the  targeted  project. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Fe^back  TO  iNFORMAnoN  Sources 

Contingency  The  Domain  Specification  is  incomplete,  ambiguous,  or  inconsistent 
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nw  1  Ttmmkt  IwiiMiiiiilii  Actiw» 


Sourc« 


Domain  Analysis  Activity 


Repose 


Contingency 


Source 

Response 


Describe  how  the  Domain  Specification  is  inadequate  and  suggest  how  it  may 
be  modified.  Proceed  with  Etomain  Imi^ementation  as  far  as  possible  with  the 
current  Domain  Spedfication. 

Unforeseen  opportunities  arise  that  cannot  be  exploited  given  the  current 
Domain  Spedfication,  e.g.,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  vdien 
the  Domain  Spedfication  was  comfdeted. 

Domain  Analysis  Activity 

Document  the  opportunities  and  the  required  changes  to  the  Domain 
Spedfication. 


4.2  Feedback  From 
Contii^ency 

Source 

Response 

Contingency 

Source 

Response 


Product  Consumers 

The  Domain  Implementation  for  a  work  product  family  is  incorrect, 
inconsistent,  or  incomplete. 

Domain  Verification  Activity 

Request  clarification  of  the  intent  of  the  Domain  Spedfication,  if  necessary. 
Modify  the  Domain  Implementation  to  satisfy  the  Domain  Spedfication. 

The  support  for  the  Application  Engineering  process  is  inefiident. 

Project  Support  Activity 

Revise  the  Domain  Implementation  based  on  Application  Engineering 
experience. 
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DE3.1.  PRODUCT  IMPLEMENTATION  ACnVITY 


1.  GETTING  STARTED 

The  Produa  Implementation  Activi^  is  the  activity  of  the  Domain  Implementatitm  Activity  for 
creating  a  Product  Implementation.  A  Product  Imfdementation  is  an  implementation  of  a  set  of  work 
product  families.  A  conventional  implementation  is  a  work  product  that  solves  a  specific  jvoblem. 
Similarly,  a  Product  Implementation  is  an  implementation  that  is  adaptable  to  decisions  supported 
by  the  work  product  faniil/s  Dedsion  Model  in  order  to  solve  any  of  a  family  of  prc^lems.  A  Itoduct 
Implementation  consists  of  Adaptable  Components  (e.g.,  code,  documentation,  and  su{^rt  for  verif- 
icationAalidation)  and  procedures,  as  needed,  for  selecting,  adapting,  and  oonqxmng  these  onnpo- 
nents.  The  Adaptable  Components  and  fK-ocedures  are  used  to  create  draft  api^ication  engineering  work 
products  in  accordance  with  an  Application  Model  that  describes  the  work  product  The  Product 
Implementation  Activity  is  performed  for  each  work  product  family  in  the  domain. 

LI  Objectives 

The  objective  of  the  Product  Implementation  Activity  is  to  inclement  the  Product  Design  using 
artifacts  that  represent  domain  knowledge  (e.g.,  code,  documentation,  test  plans)  from  existing  sys¬ 
tems.  This  implementation  is  used  by  application  engineers  to  generate  required  work  products  for 
^sterns  in  the  domain. 

1.2  Required  iNFORMAnoN 

The  Product  Implementation  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Design 

•  Decision  Model 

•  Lega(7  Products 

U  Required  Knowledge  AND  Experience 

The  Product  Implementation  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  The  design  method  used  in  specifying  the  Product  Design 

•  Existing  work  products  in  the  domain,  including  how  they  are  designed,  implemented,  and 
verified,  and  what  are  their  components  and  ardiitectures 
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•  Ihrget  language  and  i^atftmn  capalrilities 

•  The  technologies  fix  adapting  and  oomposii^  ccmpcments  into  work  products  that  make  tq)  a 
piuduct 


2.  PRODUCT  DESCRIPTION 


Name 

Purpose 


Content 


Verification 

Criteria 


Product  Imi^ementation 

A  Product  Imi^ementation  is  an  adaptable  implementation  of  a  set  of  work 
product  families.  An  application  engineer  must  be  able  to  derive  members  of 
a  work  product  family  adapting  the  Product  Imfdementation  medianically 
based  on  the  work  product  family’s  decisions  in  an  Apfdication  Model. 

A  Product  Implementation  consists  of  the  following  parts: 

•  Adaptable  Components.  An  implementation  of  eadh  work  fxoduct 
family’s  Component  Design.  Adaptable  Components  include  soft¬ 
ware,  documentation,  and  veriticationA^lidation  components  that  are 
adapted  based  on  the  work  product  family’s  Decision  Model  (see  Sec¬ 
tion  DEJ.1.1).  Adaptable  Components  may  be  derived  from  Legacy 
Product. 

•  Generation  Procedure.  An  implementation  of  a  Generation  Design  for 
selecting,  adapting,  and  composing  Adaptable  Components  into  draft 
work  products  that  satisfy  the  needs  of  the  targeted  project  as  ex¬ 
press^  by  decisions  in  an  Application  Model  (see  Section  DE  J.12). 

There  is  a  Generation  Procedure  per  work  product  family.  Each 
work-product-spedfic  Generation  Procedure  corresponds  to  a  partic¬ 
ular  set  of  Adaptable  Components  in  a  Product  Implementation. 

•  Organization  Structure.  A  grouping  of  all  the  Adaptable  Components 
that  make  up  a  Product  Implementation  (i.e.,  for  all  work  product  fam¬ 
ilies  in  the  domain).  The  grouping  supports  a  view  of  all  Adaptable 
Components  as  a  cohesive  set  of  domain-specific  reusable  work  prod¬ 
ucts.  The  grouping  must  be  consistent  with  all  Generation  Procedures. 

The  Product  Implementation  correctly  constructs  existing  or  envisioned 
members  of  the  work  product  family  as  specified  in  the  Product  Design. 


3.  PROCESS  DESCRIPTION 

The  Product  Implementation  Activity  consists  of  the  three  steps  shown  in  Figure  DE3.1-1. 


3.1  Procedure 

Follow  these  steps  for  the  Product  Implementation  Activity. 


DE3.1.  Product  ImpleaeiiiatioB  Aawiqr 


per  work  product  family  Process  Suppmt  DevelopmerU, 

2  Repeated  for  each  work  and  Domain  Verification 

product  family 

2  Repeated  for  each  work 
product  family  ccnuponent  as 
deHned  by  the  Rroduct 
Architecture  for  each  work 
product  family 

figure  DE3.1-1.  I\oduct  Implementation  Rocess 

Step:  Component  Implementation  Activity 

Action  Create  Adaptable  Components  for  the  work  product  family. 

Input  •  Product  r?quirements 

•  Product  Design 

•  Legacy  Products 

Result  Adaptable  Components 
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HaiHatics  •  Derive  AdaptaUe  Comp(»ients  from  Legacy  Products. 

•  Ensure  that  the  Adi^itaUe  Compcmeitt  satii£es  and  is  ocHisistent  with 
relevant  aspects  of  the  Product  D^gn  and  Product  Requirements. 

Step:  Generation  Implementation  Activity 

Action  Automate  or  document  a  mechanical  procedure  by  which  af^cation 

engineers  can  derive  draft  application  work  products  consistent  with  an 
Application  Model. 

frymr  •  Generation  Design 

•  Decision  Model 

•  Product  Design:  Product  Architecture 

Restdt  Generation  Procedure 

Heuristics  Ensure  that  the  Generation  Procedure  satisfies  and  is  consistent  with  relevant 

aspects  of  the  Generation  Design. 

Step:  Organize  Adaptable  Components 

Action  Organize  the  Adaptable  Components  to  facilitate  reuse  among  all  work 

product  families. 

Input  •  Adaptable  Components 

•  Generation  Procedure 

•  Product  Architecture 

Result  Organization  Structure 

Heuristics  •  Develop  an  organization  that  can  be  mapped  onto  the  available  mechanisms 

in  the  development  environment  of  the  targeted  project  (e.g.,  a  hierarchi¬ 
cal  structure  can  be  mapped  onto  files  and  directories).  If  you  have  a  reuse 
library  or  database  management  system  available,  you  can  organize  the 
components  using  more  comploi  mechanisms. 

•  Create  a  structure  that  supports  definition,  in  Process  Support 
Development,  of  procedures  by  vhich  application  engineers  can  locate, 
evaluate,  and  extract  work  products.  A  simple  approadi  is  to  make  each 
work  product  family  a  separate  directory  under  a  single  root  that  locates 
the  entire  library.  If  you  have  several  work  product  families  of  the  same 
type,  you  may  want  to  group  them  together. 

•  Use  the  Product  Architecture  as  the  basis  for  the  Organization  Structure. 
Your  structure  must  allow  use  of  all  Generation  Procedures. 
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•  Use  standard,  recognized  strictures  in  the  domain  (e^,  for  modules,  an 
information  hiding  structure)  to  organize  families.  This  can  simi^ 
browsing  among  components  in  complex  families. 

3.2  Risk  Management 

Risk  The  Product  Implementation  will  be  inconsistent  with  Product  Requirements 

for  a  work  product  family. 

Imptteaiion  Application  w^rk  products  will  be  generated  that  do  not  satisfy  the  Product 

Requirements. 

Mitigation  When  uncertainties  arise,  review  the  Domain  Specification  with  domain 

analysts  to  clarify  their  intent.  Review  the  Domain  Implementation  with  other 
experienced  engineers  to  identify  omissions  and  inconsistencies.  Derive  test 
work  products  based  on  knowledge  of  existing  or  antidpated  systems  for 
review  with  experienced  engineers. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Domain  Specification  is  incomplete,  ambiguous,  or  inconsistent. 

Sotme  Domain  Specification  Activify 

Response  Describe  how  the  Domain  Spedfication  is  inadequate,  and  suggest  how  it  may 

be  modified.  Proceed  with  Ftoduct  Implementation  as  far  as  possible  with  the 
current  Domain  Spedfication. 

Contingency  Unforeseen  opportunities  arise  that  cannot  be  exploited  given  the  current 

Domain  Spedfication,  e.g.,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  when 
the  Domain  Spedfication  was  completed. 

Sowrce  Domain  Specification  Activity 

Req^nse  Document  the  opportunities  and  the  required  changes  to  the  Domain 

Spedfication. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Product  Implementation  does  not  satisfy  the  Domain  Spedfication  for  a 

work  product  family. 

Source  Domain  Verification  Activity 

Response  Request  clarification  of  the  intent  of  the  Domain  Spedfication  if  necessary. 

Modify  the  Product  Implementation  to  satisfy  the  Domain  Spedfication. 
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Cotttinttmj 


Source 

Response 


&ipport  for  selecting,  adepting,  and  oonqxMing  Adiqptable  CoofioiMsais  is 
inefficient 

Process  Support  Develoinnent  Activity 

Revise  the  Generation  Ih^ocedures  based  on  Apf^cation  Engineering 
experience. 
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DE3.1.1.  COMPONENT  IMPLEMENTATION 

ACnVITY 


1.  GETTING  STARTED 

Component  Implementation  is  an  activity  of  the  I^oduct  Implementation  Activity  for  creating  an 
Adaptable  Component.  A  component  is  any  work  product  fragment  (e.g.,  software,  documentation, 
or  verificationA^lidation  artifact)  produced  during  the  Application  Engineering  process.  An  aj^ca- 
tion  engineering  work  product  consists  of  a  set  of  components.  An  Adaptable  Component  is  a  repre¬ 
sentation  of  a  family  of  components  that  satisfies  a  Component  Design  (i.e.,  is  adaptable  to  specified 
variations).  The  variability  of  an  Adaptable  Component  enables  application  engineers  to  extract 
components  to  form  a  draft  application  engineering  work  product. 

1.1  Objectives 

The  objective  of  the  Component  Implementation  Activity  is  to  implement  an  Adaptable  Component 
that  satisfies  a  Component  Design,  consistent  with  relevant  aspects  of  the  Product  Requirements  and 
Product  Architecture. 

1.2  Required  Information 

The  Component  Implementation  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Architecture 

•  Component  Design 

•  Legacy  Products 

U  Required  Knowledge  AND  Experience 

The  Component  Implementation  Activity  requires  domain  and  software  knowledge  and  experience 
in: 


•  Applicable  standards  and  techniques  for  design,  implementation,  and  verification  of  software 
components 

•  How  to  design,  implement,  and  verify  components  of  a  work  product  family  given  a 
specification  for  the  family 

•  The  design  and  implementation  of  existing  systems  in  the  domain 
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2.  PRODUCT  DESCRIPTION 


Name 

Purpose 

Content 


Fbrm  and 
Structure 


Adaptable  Component 

An  Adaptable  Component  is  a  component  (e^.,  of  software,  documentatkm, 
verification/validation  support)  that  is  adaptaUe  with  respect  to  variations 
specified  in  the  Component  D^gn. 

An  Adaptable  Component  is  an  implementation  of  a  famify  of  components. 
This  family  is  defined  by  a  Component  Design,  with  support  by  portions  of  the 
Product  Requirements  and  Product  Ardiitecture.  The  Component  Design 
characterizes  an  Adaptable  Component  1^  specifying  the  permissible 
adaptations  of  the  component,  along  with  the  desired  characteristics  of  its 
implementation. 

An  Adaptable  Component  is  uniquely  named  and  consists  of  two  parts:  an 
adaptability  interface  and  a  body. 

A  component  family  is  characterized  by  a  set  of  common  capabilities  and 
variations  in  those  capabilities.  The  adaptability  interface  is  a  specification  of 
a  set  of  adaptation  parameters  that  provide  for  the  characterization  and 
extraction  of  a  particular  instance  of  a  component  family. 

The  body  is  the  sum  of  the  potential  implementations  of  all  of  the  components 
in  the  family.  The  term  "potential”  is  used  because  the  parameters  are 
sufficient  to  select  any  component  family  instance  uniquely,  but  the  particular 
implementation  either  may  not  be  available  or  may  be  extracted  from  a 
representation  of  the  family  or  relevant  subfamily.  This  varies  with  the 
mechanism  used  for  implementing  adaptability  in  the  Adaptable  Component 
Three  common  mechanisms  for  implementing  an  Adaptable  Component  are: 

•  Physical  Separation.  Represent  members  of  the  component  set  as 
physically  distinct  entities  (e.g.,  in  separate  files  on  a  computer). 

•  Target-Langfutge  Mechanisms.  Use  the  language-specific  facilities  to 
represent  different  component  set  members.  Ada  generics,  C+  +  tem¬ 
plates,  Interleaf  effectivify  control,  and  WordPerfect  mao-o  features 
are  examples  of  target-language  mechanisms  for  representing  an 
Adaptable  Component. 

•  Metaprogramming.  Superimpose  a  language  for  handling  variations  on 
top  of  the  language  in  which  all  members  of  the  component  set  are 
expressed. 

These  may  be  used  separately  or  in  combination  to  implement  a  particular  set 
of  components. 

The  Booch  Ada  stack  packages  (Booch  1987)  are  an  example  of  an  Adaptable 
Component.  There  is  a  unifying  concept  of  what  a  stack  is  and  how  it  works. 
Different  stack  components  are  attracted  based  on  decisions  sudi  as: 
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DE3.X.1.  Compotal  Ii^MwiiHina  ^ctwfey 


•  T)fpe.  The  type  of  data  that  can  be  put  into  the  stack. 

•  Iteration.  Whether  an  iiklezing  mechanism  should  be  available  for 
moving  forward  and  backward  through  the  stack  in  addition  to  sim{dy 
pushing  elements  onto  and  poising  elements  off  of  the  top  of  the 
stadc. 

•  Garbage  Collection.  Whether  the  stadc  should  manage  unused  stack 
space  d^mically  for  later  use. 

•  BounSng.  Whether  the  stack  should  be  bounded  in  length. 

The  Booch  packages  use  |%sical  separation  to  implement  26  different  types 
of  stacks.  TUs  physical  separation  approadi  has  the  advantage  of  being  simple. 
If  a  family  has  10  instances,  there  are  10  implementations  and  eadi  can  be 
written  and  verified  independently.  Physical  separation  does  not  take 
advantage  of  similarities  among  the  instances,  however,  nor  does  it  make 
explicit  how  variabilities  determine  the  content  of  each  instance. 

Ala  provides  generic  packages  as  a  standard  fiaality  that  you  can  use  k>  implement 
a  00^  MapaAAc  Gcxi^xxnent  xxhose  instances  differ  mily  in  the  values 
well-defined  i^acehdders  diat  can  be  substituted  at  ocanpOe  time.  The  ‘‘Q'pe” 
variability  of  stack  packages  may  be  rqxesented  using  a  generic  package.  The 
I^aceholders  are  parametos  defi^  in  the  adaptability  intoface  (ff  the  AdaptaUe 
CompcMienL  This  approach  has  the  advantage  representing  variabilities  ^  the 
component  family  mcx’e  oonpactfy  and  unifixmty,  however,  onfy  a  simple  ffvm 
parameter  substituticm  is  suppnted. 

A  meuprpgramming  approach  (Campbell  1989)  uses  a  prqxooessing  mechanism 
m  extract  a  concrete  compcment  from  an  AlaptaUe  Ccxnponent  This  approach 
embeds  target  text  fragmoits  a  wcxrk  product  (e.g,  code,  documentation, 
verificadcHiA'alidaticMi  suppOTt)  with  a  siperinposed  metaprogrammpg  notation. 
The  metaprogramming  nc^atkm  pedfies  how  the  target  fi:agmrats  are  to  be 
combined  and  adapted,  based  cm  the  parameters  in  the  adaptal^ty  interface  of  the 
Adaptable  ComponenL  'Epical  metaprogjammiiig  adaptaticms  indude: 

•  Substitution  of  parameter  values 

•  Conditional  indusion  of  tot  fragments 

•  Repetition  of  text  fragments 

•  Definition  and  in-line  instantiation  of  parameterized  fragments 

This  approach  provides  greater  fiexibiliQr  in  representing  a  component  family 
compac^y  but  results  in  more  complex  desniptions.  Since  many  implementa¬ 
tions  may  be  derived  from  a  single  description,  domain  engineers  must  both 
manually  inspect  that  description  and  extract  and  verify  representative 
instances.  Example  DE3.1.1-1  illustrates  a  small  fragment  of  a  Component 
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Imptemeatatkm  fior  a  work  product  £ui%  of  tte  TLC  doBiaiiL  This  eaoua^ 
contains  a  portkm  tl»  impleiiieittatkm  for  die  Adaptdiie  Corafxmeiit 
specified  in  Example  DE22.AJ2rl. 


Pedotrnn  Lanes  with  Pudi  Buttoos  (ILC-PL-PB-l) 

Pwpoic:  The  purpoee  of  this  segment  is  to  provide  the  fimctioaelity  needed  by  die  oootroOer  si^ment  to  mensge  the 
pedestrian  lane  indicstocs  St  the  intersection  coBsideripg  the  input  ptovided  by  the  trip  medwwsm. 

DascripUen:  The  a^ment  b  oooqxjsed  of  those  functions  needed  to  turn  on  and  off  the  walk  rod  don't  walk  iodicatan 
present  in  the  pedestrian  lanes  of  the  mtersectionuTbe  fimctions  needed  to  rand  and  reset  the  pedeatrbn  lane^  push 
buttons  are  also  contained  in  this  segmentThe  pedestrian  lanes*  purii  buttons  asBume  a  <  COMP_lnt*rface  >  inteifMe 
tothetrafBcU^tmdicatars.  ' 

System  Capabilities; 


<lf  COMP_blinkIii|^rate  s  yet  then> 

The  TLC  ^stem  A«ll  be  capable  of  setting  the  blinking  rate  srsocaated  with  the  walk-dont  walk  indicators  at  the 
pedestrian  lanes. 

<cndif> 


Examine  DE3.1.1<1.  Fragment  of  the  TUC  Component  Implementation  for  the  gystem/Segment  Specification 


Waric  Piroduct  Funily 

l^ripcation 

Criteria 

•  The  Adaptable  Components  implement  their  specifications  as  defined  in 
the  Product  Architecture  and  Component  Designs. 

1 

•  The  Adaptable  Components  produce  the  correct  variations  in  concrete 
components. 

•  Behaviors  or  constraints  imposed  by  Product  Requirements  or  Product 
Architecture  on  the  Adaptable  Component  are  all  supported. 

3.  PROCESS  DESCRIPTION 

The  Component  Implementation  process  consists  of  all  activities  necessary  for  im[dementing  an 
Adaptable  Component  to  its  Component  Design  specifications,  consistent  with  relevant  parts  of  the 
Product  Ardiitecture  and  Product  Requirements.  This  invcdves  the  design,  imidementation,  and  veri¬ 
fication  of  the  work  product  family  of  software,  documentation,  or  test-support  components.  It  may 
involve  the  reengineering  of  existing  components  of  work  products  fi’om  previously  built  ^tems.  The 
Component  Implementation  Activity  consists  of  the  three  steps  shown  in  IHlgure  DEJ.1.1-1. 

3.1  Procedure 

Fbllow  these  steps  for  the  Component  Implementation  Activity. 

Step:  Design  the  Component’s  Internal  Structure 
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RgureDEJwl.l*l.  Qxnpooentln^eineiiUtioonrooess 


Action 

Input 


Resiit 

Heuristies 


Oreate  an  inmnal  design  that  suj^rts  the  necessary  variation  among  the 

members  of  the  component  set  rej^resented  by  the  adaptable  component 

•  Component  Design 

•  Product  Architecture 

•  Legacy  noducts 

•  AdapuMe  Component  Internal  design 

•  Candidale  Components 

•  The  Ad^itable  Components  internal  design  must  satisfy  its  Component 
Design  ^edfication.  The  structures  of  the  Product  Arddtecture  may  im¬ 
pose  ad^onal  requirements  on  the  internal  structure  (e.g.,  for  concur¬ 
rency  or  level  of  performance)  or  define  constraints  on  how  other 
conqxneots  are  used  in  the  imjdementation. 

•  Enviskm  how  to  implement  required  members  of  the  component’s  work 
product  fiunily.  Create  structures,  according  to  the  design  method  used, 
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that  characterize  the  required  inqdementatkHL  Puameterise  each 
structure,  if  af^opriate,  with  adapta^ty  parameters  that  vary  the  rixuc- 
ture,  as  required,  for  different  members  of  the  omnponent  family. 
Consider  the  required  operations  of  the  members. 

•  Determine  whether  a  suitable  component  that  af^ozimates  one  of  these 
desired  instances  is  available  from  Legacy  Products.  Identify  and  evaluate 
the  quality  of  each  sudi  component  and  designate  it  as  a  Camlidate  Com¬ 
ponent  for  further  use.  Determine  viudi  AdaptaUe  Gmoponent  variatkms 
are  im^didtfy  addressed  by  this  selected  Candidate  Component. 

•  Consider  starting  with  the  internal  designs  of  identified  Candidate 
Components.  Portions  of  several  candidate  components  may  be  used 
collectively  to  implement  the  Adaptable  Component.  These  components 
may  implement  different  variations  that  will  be  required  for  the  family. 
Characterize  which  instance  of  the  family  corresponds  to  eadi  component 
(i.e.,  1^  its  parameter  values).  Consider  whether  eadi  design  is  sufGdently 
well-engineered  and  representative  of  the  family,  or  at  the  least  of  a 
subfamily,  to  provide  substantial  leverage  in  being  refined  to  represent 
other  variations  and  the  family  as  a  whole.  Consider  that  they  may 
represent  different  subfamilies  that  should  be  structured  differently.  See 
if  their  designs  can  be  unified  using  variations.  Be  sure  you  can  still  derive 
each  of  the  components  with  an  acceptable  structure. 

•  Use  adaptation  mechanisms  (e.g.,  target-language  mechanisms, 
metaprogramming)  already  present  in  the  existing  work  products. 

Step:  Implement  the  Component 

Action  Elaborate  the  internal  design  to  implement  the  Adaptable  Component. 

Input  •  Adaptable  Component:  Internal  design 

•  Component  Design 

•  Product  Architecture 

•  Candidate  Components 

•  Legacy  Products 

Result  Adaptable  Component 

Heuristics  •  Fill  in  the  internal  structure  with  the  details  of  the  implementation.  Keep 

in  mind  how  the  adaptabilities  affect  the  content  of  the  parts  of  the 
structure. 

•  If  suitable  Candidate  Components  were  used  in  creating  the  internal 
design,  then  the  implementations  of  those  components  can  be  useful  as  the 
starting  point  in  implementing  the  Adaptable  Component. 
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•  Parts  of  the  Adaptable  Component  might  have  to  be  engineered  firmn 
snatch  if  all  elements  of  the  Adaptable  Component’s  imfdementation  can¬ 
not  be  obtained  from  existing  Candidate  Components.  These  areas  should 
be  given  much  greater  thought  to  ensure  that  you  produce  the  correct 
content. 


•  Consider  reengineering  existing  application  engineering  work  products 
(e.g.,  Legacy  Products)  to  increase  their  reusability.  For  examfde,  you 
might  want  to  replace  arbitrary  limits  on  data  structure  size  with  generic 
parameters.  You  should  consider  this  if  it  will  relax  or  remove  constraints 
in  your  Decision  Model.  You  should  take  into  account  any  documentation 
or  coding  standards  for  the  targeted  project  when  you  reengineer  existing 
work  products. 

Step:  Verify  the  Component 


Action 

Input 


Result 

Heuristics 


Verify  that  the  Adaptable  Component  satisfies  all  relevant  specifications. 

•  Adaptable  Component 

•  Component  Design 

•  Product  Architecture 

•  Product  Requirements 

•  Candidate  Components 

Verified  Adaptable  Component 

•  Perform  rigorous  inspection  of  the  Adaptable  Component  by  other 
experienced  engineers.  The  Component  Design,  as  well  as  relevant  parts 
of  the  Product  Requirements  and  Product  Architecture,  should  be  verified 
as  being  satisfied. 

•  Derive  representative  instances  of  the  Adaptable  Component  and  test 
those  instances  in  a  conventional  fashion  to  see  if  they  operate  correctly. 
One  part  of  this  activity  is  the  creation  of  test-case  scenarios  that  can  be 
used  in  regression  testing  of  the  Adaptable  Component  when  it  is  modified 
in  the  future.  These  scenarios  may  be  made  adaptable  to  the  same  parame¬ 
ters  as  the  Adaptable  Component  itself  so  that  a  scenario  can  be  derived 
for  a  particular  test  instance. 

•  Rederive  the  Candidate  Components  that  influenced  the  implementation 
of  the  Adaptable  Component.  The  original  and  derived  instances  can  then 
be  compared  to  see  if  and  how  they  differ  and  whether  an  equivalent  result 
can  be  produced. 

•  Use  of  a  Candidate  Component  may  have  been  based  on  assurances  that 
the  component  received  with  respect  to  certain  desired  properties  such  as 
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correctness,  reUatnlity.  cotificatioii,  and  trust  (in  the  seoni^  soise). 
Note,  however,  that  nxxh&atkm  of  the  component  can  invalklate  some 
of  these  assurances  (Le^  certificatkm  aiKl  trust).  It  is  impmtant  to  verify 
that  the  desired  properties  are  retained  udien  the  component  is  extracted 
from  the  resulting  Adaptable  Component. 


3.2  Risk  Management 


Risk 

litigation 

Risk 


ImpUcation 

Mtigation 


Risk 


Indication 

Mitigation 


Certain  cranbinations  oS.  adaptabOify  are  not  fully  si|3ported  in  the  Adaptable 
CcxnpcMnent 

In  verifying  the  Adaptable  CcHnponent,  use  bounds-coverage  techniques  to 
identify  a  variety  of  adaptabilify  combinations  in  deriving  test  instances. 

The  effort  required  to  im{^ement  all  specified  adaptabilities  for  an  Adaptable 
Component  is  not  viable  compared  to  that  renuired  to  develop  cono-ete 
components  which  suf^rt  a  si^e  ^tem  developunent  effort. 

Only  a  subfamily  of  the  Adaptable  Component  will  be  available  for  {ffoduction 
of  systems  in  the  domain. 

Implement  the  variations  required  for  the  targeted  (voject  under 
development.  The  develofnnent  of  these  variations  may  require  less  effort 
than  developing  all  possible  variations  and  can  be  refined  as  sdditional  needs 
arise.  The  Adaptable  Component  can  be  evolved  to  a  completed  state  over 
several  development  iterations  of  a  system  or  systems. 

Determining  the  value  of  existing  components  as  a  basis  for  the  Adaptable 
Component  will  require  too  much  effort  (e.g.,  too  many  components  to  search 
through,  too  labor  intensive  to  look  through  complicated  components,  too 
difficult  to  determine  whether  a  component  is  correctly  implemented). 

Effort  to  evaluate  and  reengineer  casting  components  exceeds  the  effort  to 
create  the  Adaptable  Component  from  snatch. 

If  there  are  too  many  existing  components  to  seardi  through  to  find  a  good 
baseline  component,  limit  the  amount  of  effort  dedicated  to  the  search,  and 
use  the  best  approximation  that  results  from  the  limited  search. 

If  looking  through  complicated  components  is  too  labor-intensive,  reduce  the 
number  of  components  that  will  be  reviewed.  If  the  component  is  overly 
complicated,  relying  on  higher-level  documentation  (i.e.,  requirements, 
high-level  design,  or  testing  documentation)  of  the  component  as  an  indicator 
of  its  worth  may  be  benefidal.  Reviewing  documentation  on  the  existing 
component  is  likely  to  take  less  effort  than  reviewing  code. 

If  determining  the  correctness  of  the  component  is  difficult,  then  determining 
correctness  from  previous  test  documentation  may  be  sufficient.  Reliance  on 
existing  components  may  be  greater  if  engineers  are  available  ^o  developed, 
or  at  least  used,  the  existing  components. 
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Ksk 

ImpUeation 

Mitigation 


Risk 


Implication 


Mitigation 


Some  component  set  members  are  not  (vesent  in  the  Adaptable  CompcmenL 

^plication  engineers  will  iK>t  be  able  to  derive  certain  apfdicatimi 
engineering  work  products. 

When  verifying  the  Adaptable  Component,  make  sure  you  can  derive  at  least 
a  set  of  components  equivalent  to  those  that  went  into  creating  the  Adaptable 
Component.  (If  you  reengineered  components,  you  may  not  be  able  to  derive 
an  identical  set) 

Modifying  the  baseline  component  may  invalidate  assurances  of  quality  that 
the  component  possessed  (e.g.,  certification). 

Modifying  a  certified  component  will  require  that  the  resulting  Adaptable 
Component  must  pass,  once  again,  the  tests  required  for  assuraiK%  of  given 
properties. 

•  Concentrate  efiort  on  areas  of  particular  concern.  If  the  given  properties 
are  less  important  for  the  component  family  as  a  whole,  treat  that  particu¬ 
lar  member  as  a  spedal  case  (i.e.,  a  component  subfamily  in  its  own  right). 
That  is,  if  a  component  family  contains  several  members,  only  one  of  which 
is  certified,  define  two  Adaptable  Components,  one  whose  component 
family  contains  the  certified  member  and  another  which  contains  all  the 
uncertified  members. 

•  liy  to  retain  the  essential  nature  of  the  baseline  component  in  the 
Adaptable  Component  so  that  proving  assurance  of  given  properties  is  not 
an  expensive  process. 


4.  INTERACTIONS  WITH  OTHER  ACnVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Component  Design  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Component  Design  Activify 

Response  Describe  how  the  Component  Design  is  inadequate,  and  suggest  how  it  may 

be  modified.  Proceed  with  Component  Implementation  as  far  as  possible  with 
the  current  Component  Design. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Component  Implementation  does  not  satisfy  the  Component  Design. 

Source  Domain  Verification  Activity 

Response  Request  clarification  of  the  intent  of  the  Component  Design,  if  necessary. 

Modify  the  Component  Implementation  to  satisfy  the  Component  Design. 
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DE.3.1.2.  GENERATION  IMPLEMENTATION 

ACTIVITY 


1.  GETTING  STARTED 

Generation  Implementation  is  an  activity  of  the  Product  Implementation  Activity  for  creating  a 
Generation  Procedure.  A  Generation  Procedure  is  a  precise  description  of  how  to  derive  draft  ap¬ 
plication  engineering  work  products  consistent  with  the  decisions  in  an  Application  Model  for  a  work 
product  family.  A  Generation  Procedure  may  be  automated  or  may  take  the  form  of  a  precise 
description  that  application  engineers  can  mechanically  follow  to  create  work  products. 

1.1  Objectives 

The  objective  of  the  Generation  Implementation  Activity  is  to  create  a  Generation  Procedure  as 
specifl^  by  a  Generation  Design. 

1.2  Required  Information 

The  Generation  Implementation  Activity  requires  the  following  information; 

•  Generation  Design 

•  Product  Architecture 

•  Decision  Model 

•  Component  Designs 

13  Required  Knowledge  and  Experience 

The  Generation  Implementation  Activity  requires  knowledge  and  experience  in: 

•  The  notation  used  in  specifying  the  Generation  Design 

•  The  technologies  for  adapting  and  composing  components  into  work  products 

2.  PRODUCT  DESCRIPTION 

Name  Generation  Procedure 
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Purpose  This  is  a  procedure  that  an  application  engineer  uses  to  aeate  draft 

application  engineering  work  products  for  a  member  of  a  work  product  family 
using  Adaptable  Components.  This  procedure  is  either  implemented  as  a 
product  generator  or  documented  as  a  manual  procedure. 

Content  The  Generation  Procedure  is  a  procedural  description  for  producing  an 

application  engineering  work  product  that  satisfies  the  mappings  of  a 
Generation  Design.  The  Generation  Procedure  describes  how  to  select 
appropriate  Adaptable  Components,  how  to  apply  decisions  from  an 
Application  Model  to  adapt  them,  and  how  to  compose  them  to  create  the 
work  product  in  final  form. 

The  form  of  the  Generation  ftocedure  depends  on  whether  the  procedure  is 
automated  or  manual.  The  Generation  Procedure  is  either  implemented  as  an 
automated  product  generator  or  documented  as  a  manual  procedure  to  be 
followed  by  application  engineers.  If  the  manual  form  is  chosen,  then  the 
Generation  Procedure  form  is  likely  to  resemble  the  form  of  a  Generation 
Design.  If  the  Generation  Procedure  is  implemented  in  the  form  of  a  product 
generator,  however,  it  will  be  a  conventional  software  program. 

Verification  •  The  Generation  Procedure  for  a  work  product  family  can  be  used  to 

Criteria  produce  application  engineering  work  products  that  exhibit  the  internal 

organization  specified  in  the  Product  Architecture. 

•  The  Generation  Procedure  for  a  work  product  family  can  be  used  to  produce 
application  engineering  work  products  that  satisfy  the  Produa  Requirements. 

•  If  a  manual  form  is  used,  the  Generation  Procedure  for  a  work  product 
family  clearly  desaibes  how  draft  application  engineering  work  products 
are  constructed  from  Adaptable  ^mponents  based  upon  decisions 
contained  in  an  Application  Model. 

3.  PROCESS  DESCRIPTION 

The  Generation  Implementation  Activity  consists  of  the  two  steps  shown  in  Figure  DE.3.1.2-1. 

3.1  Procedure 

Perform  one  or  both  of  the  following  two  steps.  The  appropriate  action  depends  on  what  automation 
you  determine  to  have  a  significant  payoff  in  Application  Engineering. 

Step:  Document  the  Generation  Procedure 

Action  Document  some  or  all  of  the  Generation  Design. 

Input  •  Generation  Design 

•  Product  Architecture 

•  Decision  Model 

•  Component  Designs 


Form  and 
Structure 
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I 


to 

Process  Support  DevoIopnutU  and  Pmjtet  Support 

^  One  w<»k  product  component 
per  work  product  famfly 

2  Repeated  for  each  work 
product  family 

Figure  DEJ.1.2-1.  Generation  Imj^ementation  Froceaa 
Result  Generation  Procedure 

Heuristics  •  The  Generation  Design  is  a  precise  description  ofthe  required  Generation 

Procedure.  Document  the  procedure  in  a  form  that  is  usable  by  application 
engineers. 

•  Include  a  desaiption  of  how  components  are  composed  to  form  a  work 
product  consistent  with  its  Product  Architecture. 

•  Include  a  description  of  how  to  access  the  decisions  in  an  ^plication 
Model  for  a  work  product  family.  The  Decision  Model  provides  the 
organization  of  the  dedsions’  conceptual  schema. 

Step:  Automate  the  Generation  Procedure 

Action  Develop  automated  tools  that  implement  some  or  all  of  the  Generation 

Procedure  as  defined  in  the  Generation  Design. 

Input  *  Generation  Design 

•  Product  Architecture 

•  Decision  Model 

•  Component  Designs 
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Jteufr  Generation  Procedure 

Heuristics  •  If  the  dedsion-making  Activity  in  Application  Engineering  is  supported  by 

automation,  then  the  Generation  I^ocedure  must  access  the  decisions.  If 
the  activity  is  not  automated,  then  there  must  be  an  automated  mechanism 
for  providing  the  decisions  as  input  to  the  Generation  Procedure.  The  De¬ 
cision  Model  provides  the  organization  of  the  decisions’  conceptual  sdie- 
ma. 

•  If  a  metaprogramming  technology,  such  as  described  in  the  Component 
Implementation  Activity  (see  Section  DE.3.1.1),  is  used  to  implement  the 
Adaptable  Components,  then  the  same  metaprogramming  technology  is 
used  to  instantiate  those  components.  Metaprogramming  technolc^  may 
also  be  useful  in  implementing  portions  of  the  Generation  Procedure 
itself. 

•  Creating  an  automated  Generation  Procedure  is  a  software  development 
task.  It  requires  the  design  of  the  required  program,  implementation  to 
that  design  in  a  programming  language,  testing  to  verify  that  the  resulting 
program  implements  the  Generation  Design  correctly,  and  documenta¬ 
tion  so  that  the  program  can  be  correctly  modified  as  the  Generation 
Design  changes. 

•  Tbols  such  as  the  UNIX  make  facility  may  be  useful  in  automating  the 
procedure  for  composing  adapted  components  into  draft  work  products. 

3.2  Risk  Management 

None 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  to  Information  Sources 

Contif^ency  The  Generation  Design  for  a  work  product  family  is  incomplete,  ambiguous, 

or  inconsistent. 

Source  Generation  Design  Activity 

Response  Describe  how  the  Generation  Design  is  inadequate,  and  suggest  how  it  may  be 

modified.  Proceed  with  Generation  Implementation  activity  as  far  as  possible 
with  the  current  Generation  Design. 

4.2  Feedback  From  Product  Consumers 

Contir^ency  The  Generation  Procedure  for  a  work  product  family  does  not  satisfy  the 

Generation  Design. 
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Source 

Domain  Verification  Activity 

Reqnnse 

Request  clarification  of  the  intent  of  the  Generation  Design  if  necessary. 
Modify  the  Generation  Procedure  to  satisfy  the  Generation  Design. 

QuOit^eacy 

A  manual  Generation  Procedure  is  difiBcult  to  use. 

Source 

Project  Support  Activity 

Response 

Investigate  new  forms  for  conveying  the  Generation  Procedure  to  the 
application  engineers. 

Caitu^mcy 

The  Generation  Procedure  cannot  be  used  in  its  current  form  in  the 
Application  Engineering  process. 

Source 

Process  Support  Development  Activity 

Reqtonse 

Revise  the  Generation  Procedure  (e.g.,  improve  automation  or  upgrade 
documentation)  so  that  it  can  be  effectively  used  tty  application  engineers. 
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DE  PROCESS  SUPPORT  DEVELOPMENT 

ACTIVITY 


1.  GETTING  STARTED 

The  Process  Support  Development  Activity  is  the  activity  of  Domain  Imi^ementation  for  creating  the 
Process  Support  component  of  Domain  Im[^ementation.  Process  Suf^rt  is  the  infrastructure  that 
supports  the  practice  of  Application  Engineering  by  defining  the  prot^ures  and  standards  by  which 
apfdication  engineers  develop  applications  (i.e.,  the  Ap[^cation  Engineering  process).  It  optionally 
{MTOvides  automated  mechanisms  which  support  the  effective  and  correct  performance  of  the 
reuse-related  activities  of  Application  Engineering. 

1.1  Objectives 

The  objectives  of  die  Process  Support  Development  Activity  are  to: 

•  Document  policies  and  procedures  that  fadh'tate  reuse  of  existing  work  products  during 
activities  of  an  Application  Engineering  process 

•  Determine  the  appropriate  degree  of  automation  that  will  support  the  ^plication 
Engineerfaig  process  and  construct  the  automated  support 

12  Required  IfooRMATioN 

The  I^ocess  Support  Development  Activity  requires  the  following  information: 

•  Domain  Definition 

•  Domain  Sjpedfication 

•  Product  frnplementation 

13  Required  Knowledge  AND  Experience 

The  Process  Sityport  Development  Activity  requires  domain  kno^edge  and  experience  in: 

•  How  application  engineers  resolve  issues  in  constructing  work  products  in  the  domain 

•  The  concepts  and  structures  by  which  domain  eiqierts  communicate  the  distinguishing 
features  of  work  products  in  the  domain 
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Documenting,  in  a  and  maUe  fbns.  the  use  of  convoitioBs,  poUdes,  and  proonkffes 

Software  production  processes,  methods,  and  practices 


2.  PRODUCT  DESCRlPnON 


Name 

Purpose 


Content 


Hr^kation 

Criteria 


Process  Suf^xMt 

Process  Support  is  a  description  and  explanation  of  the  conventions  by  winch 
af^cation  engineers  produce  work  products  (via  activities  of  the  Apfdication 
En^eering  process)  and  automated  support  for  cfBdent  performance  of  the 
A{^cation  En^eering  process. 

Process  Support  consists  of  two  parts: 

•  AppUcerion  Eng^neerit^  Useris  Guide.  A  document  that  guides 
api^ication  engineers  in  how  to  oqdoit  reuse  opportunities  to  [xoduce 
a  set  of  supported  work  products. 

•  Ai^iieation  Enpneering  Environment.  Automated  mechanisms  that 
help  the  application  engineers  reuse  work  products.  This  includes  the 
mechanisms  that  create  the  application  engineers’  view  of  the  orga¬ 
nization  of  the  Adaptable  Components  and  those  tools  used  to  access 
the  Adaptable  Components. 

•  Draft  work  {x-oducts  for  the  family  can  be  produced  using  the  ^}piication 
Engineering  Environment  by  following  the  User’s  Guide. 

•  Process  Support  provides  the  ability  to  access  all  work  product  families 
supported  by  Produa  Implementation. 


2.1  Appucahon  Engineering  USER’S  Guide 


Purpose 


Content 


Form  and 
Structure 

Verification 

Criteria 


The  ^)plication  Engineering  User’s  Guide  provides  a  detailed  description  of 
how  application  engineers  can  use  the  ^plication  Ei^eering  Process 
Support  to  aq>loit  reuse  opportunities.  This  guide  aqu-esses  the 
decision-making  process  that  a]:q)lication  engineers  follow  for  a  domain. 

The  Application  Engineering  User’s  Guide  instructs  application  engineers  in 
how  to  recognize  reuse  opportunities  and  how  to  select,  adapt,  and  compose 
reusable  components  of  a  work  product  family  to  eiq}loit  reuse  opportunities. 
This  guide  also  designates  and  oqdains  the  effective  use  of  automated 
mechanisms  that  sufqwrt  the  process. 

The  User’s  Guide  should  conform  to  your  organization’s  standards  and 
guidelines  for  documentation. 

The  User’s  Guide  desoibes  how  to  select,  jdapt,  and  compose  components  for 
every  work  product  famify  in  the  Product  Imfdementation. 
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2.2  Appucation  Engineering  Environment 


Purpose 


Content 


Form  and 
Structure 


Verification 

Criteria 


The  Application  Engineering  Environment  consists  of  all  automated 
mechanisms,  desaibed  in  the  User’s  Guide,  that  provide  access  to  Adaptable 
Components  for  all  domain-specific  work  products  that  ai^icadon  engineers 
reuse.  The  Application  Engineering  Environment  automates  the  mechanical 
portions  of  the  (wocess  for  increased  consistent^  within  a  product  and  less 
opportunities  for  undetected  error  in . 

The  Application  Engineering  Environment  consists  of  both  tools  that  are  part 
of  the  host  operating  system  and  tools  developed  during  this  activity.  Ibgether, 
they  define  a  view  of  the  Adaptable  Components,  along  with  a  set  of 
mechanisms  that  allow  application  engineers  to  access  these  components. 

•  The  tools  adhere  to  the  organization’s  standards  and  conventions  for  its 
software  development  environment. 

•  The  view  of  the  Adaptable  Components  provided  by  the  Application 
Engineering  Environment  must  facilitate  the  tasks  application  engineers 
undertake  when  using  it.  The  Application  Engineering  User’s  Guide 
describes  these  tasks  in  detail. 

•  From  the  application  engineers’  perspective,  the  structure  of  the 
Adaptable  Components  is  determined  by  the  tools  with  which  they  access 
the  structure.  These  tools  may  or  may  not  hide  the  actual  structure. 

•  The  Application  Eng^eering  Environment  must  fadlitate  application 
engineers  being  able  to  unambiguously  locate,  evaluate,  and  extract  work 
products. 

•  All  automated  tools  described  in  the  User’s  Guide  exist  and  behave  as  the 
User’s  Guide  states.  All  Adaptable  Components  produced  during 
Component  Implementation  Activities  are  accessible. 

•  Automated  mechanisms  contain  no  residual  errors. 


3.  PROCESS  DESCRIPTION 

The  Process  Support  Development  Activity  consists  of  all  activities  necessary  to  create  appropriate 
Process  Support  for  an  application  engineering  work  product  family.  You  perform  this  activity  for  eadi 
work  product  family,  augmenting  the  User’s  Guide  and  Application  Engineering  Environment,  to 
support  the  new  or  revised  work  product  families.  In  many  respects,  this  activity  involves  work  whidi 
is  similar  to  that  of  a  conventional  software  development  project.  Furthermore,  if  you  decide  to  auto¬ 
mate  some  or  all  of  the  Application  Engineering  process  (i.e.,  aeate  an  Application  Engineering  En¬ 
vironment),  then  you  apply  software  development  methods  to  accomplish  that  goal.  The  Process 
Support  Development  Activity  consists  of  the  two  steps  shown  in  Figure  DE.3.2-1. 

3.1  Procedure 

Follow  these  steps  for  the  Process  Support  Development  Activity.  Perform  these  steps  in  the  order 
listed  but  iterate  through  them  until  you  are  satisfied  with  the  work  product  as  a  i^ole. 
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Figure  DEJ^l.  Rooess  Support  Development  IVooess 


Step:  Develop  the  Application  Engineering  User’s  Guide 


Action 


Input 


Routt 

Heuristics 


Create  a  detailed  guide  for  application  engineers  whidi  instructs  them  on  how 
to  perform  every  aspect  of  ^plication  Engineering  including  manual  steps 
and  effective  use  of  any  automated  mechanisms. 

•  Process  Requirements 

•  Domain  Definition 

•  Domain  Spedfication 
Application  Engineering  User’s  Guide 

•  Present,  in  as  much  detail  as  possible,  a  desCTiption  of  how  application 
engineers  would  locate  and  generate  work  {nroducts  in  the  Apj^cation  En¬ 
gineering  Process  Su[^rt.  Dy  to  describe  reuse  as  a  series  of  steps  that 
application  engineers  can  Ibllow.  Do  so  in  terms  of  any  procedures  and 
standards  your  organization  has  for  performing  a  given  activi^.  (Sedion 
AE  desaibes  a  prototypical  sequence  of  steps  for  an  ^jplication 
Engineering  activity.) 
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•  Provide  an  overview  that  helps  af^lication  engineers  understand  the  types 
of  work  products  in  the  domain.  You  can  draw  on  the  components  of  the 
Domain  Definition  for  this  overview. 

•  Create  scenarios  that  describe  an  ^)plication  Engineering  activity  involving 
reuse.  These  scenarios  will  help  you  organize  reuse  and  iiux>rporate  it  into 
your  ^>plication  En^heering  process.  Use  the  targeted  {vojecfs 
environment  as  the  basis  for  your  scenarios. 

•  Describe,  based  on  the  Process  Requirements,  the  activities  where 
application  engineers  can  reuse  work  products  of  this  type. 

•  Each  work  product  family  has  its  own  Decision  Model  and  Generation 
Procedures.  A  simple  way  to  keep  them  separate  is  to  describe  each  work 
product  family  in  its  own  section. 

•  When  you  have  described  reuse  for  several  work  product  families,  you  will 
notice  similarities  in  the  procedures.  You  should  note  these  in  the  User’s 
Guide  as  preliminary  organizational  standards  for  reuse.  Some  of  these 
may  come  from  conventions  that  exist  in  your  organization,  whereas  others 
may  have  been  introduced  to  facilitate  reuse.  Be  sure  that  the  conventions 
you  describe  do  not  interfere  with  Application  Engineering. 

•  Describe  reuse  of  a  work  product  as  a  procedure,  i.e.,  a  set  of  steps  to 
follow.  Make  each  step  of  reuse  as  mechanical  as  possible.  This  will  help 
you  eliminate  ambiguity  and  determine  which  portions  you  can  automate. 

•  You  can  communicate  certain  concepts  to  application  engineers  using 
domain  engineering  work  products  developed  for  the  work  product  family: 

-  Use  Product  Requirements  to  describe  the  common  traits  of  all 
work  product  family  members  and  the  characteristics  of  individual 
members. 

-  Incorporate  concepts  firom  the  Procedure  for  Work  Product 
Creation  (from  Process  Requirements)  into  the  descriptions  of 
steps  for  reusing  work  products.  Ideally,  you  can  present  reuse  to 
application  engineers  as  a  desirable,  but  optional,  step  in  creating 
a  work  product. 

-  Use  the  Decision  Model  to  describe  the  decisions  the  application 
engineer  must  make  to  identify  an  individual  work  product  family 
members.  Incorporate  engineering  judgment  and  domain 
knowledge  that  domain  experts  use  to  formulate  a  set  of  answers. 

-  Use  the  Product  Architecture  to  describe  the  internal 
organization(s)  of  a  member  of  the  work  product  family. 

-  Use  Component  Designs  to  jx-ovide  detailed  interface  information 
that  will  help  application  engineers  determine  whether  they  can 
use  a  given  component  in  their  work  product. 
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-  Use  Generation  Ftocedures  to  describe  how  to  extract  a  member 
of  the  work  product  family.  Note  that  the  Generation  Procedure 
does  not  account  for  the  automation  in  the  Af^cation  Engineer¬ 
ing  Environment.  Automation  may  allow  application  engineers  to 
use  tools  to  perform  certain  steps;  describe  the  tools,  not  the  steps. 

•  You  should  understand  (and  document)  the  expertise  expected  of  ap{^cation 
engineers.  This  will  affect  the  type  of  information  you  place  in  the  User’s 
Guide. 

Step:  Develop  the  Application  Engineering  Environment 

Action  Design,  implement,  and  verify  the  automated  mechanisms  needed  to  support 

the  Application  Engineering  process. 

Input  •  Application  Engineering  User's  Guide 

•  Product  Implementation 

•  Product  Architecture 

Result  Application  Engineering  Environment 

Heuristics  •  The  Application  Engineering  User’s  Guide  specifies  what  aspects  of  the 

Application  Engineering  process  are  automated.  Revise  the  User’s  Guide 
if  this  cannot  be  fiilly  satisfied. 

•  Creating  an  Application  Engineering  Environment  is  a  software  develop¬ 
ment  task.  You  must  design  an  environment,  implement  that  design  in  a 
programming  language  (or  via  equivalent  commercially-available  soft¬ 
ware  technology),  and  test  it  to  verify  that  the  resulting  environment  im¬ 
plements  the  Application  Engineering  User’s  Guide  correctly. 

-  You  must  provide,  at  a  minimum,  enough  automation  to  allow 
application  engineers  to  access  the  Adaptable  Components.  In  this 
step,  specify  other  tools  that  you  think  be  a  cost-effective  way  to 
simjMify  the  steps  of  reuse. 

-  If  the  User’s  Guide  asks  application  engineers  to  browse  through 
the  ^plication  Engineering  Process  Support,  consider  using  file 
system  directory-changing  commands. 

•  Reduce  your  up-front  development  costs  by  taking  advantage  of  available 
technology  to  automate  various  activities  within  the  infi'astructure.  Fbr  ex¬ 
ample,  there  are  planning  and  sdieduling  tools  for  project  management; 
object-oriented  databases  and  user  interface  tools  that  can  support  speci¬ 
fying  an  Application  Model;  testing,  prototyping,  and  environment  simu¬ 
lation  tools  for  validation;  simulation  and  (^amic  assessment  tools  for 
assessment;  and  metaprogramming  and  intern  generation  tools  for  prod¬ 
uct  generation.  However,  you  must  also  consider  what  resources  you  will 
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need  to  integrate  these  or  other  technologies  into  a  coherent 
infrastructure. 

-  Determine  how  you  want  application  en^neers  to  view  the 
Adaptable  Components  and  how  you  want  them  to  perform  the 
task  of  locating,  evaluating,  and  extracting  them.  The  tools  you  al¬ 
low  them  to  use  influence  this  view.  At  a  minimum,  you  can  use  the 
native  operating  system  tools  to  browse  and  manipulate  the  file 
structure  specified  as  the  Organization  Structure  in  the  Product 
Implementation. 

-  The  Organization  Structure  of  Product  Implementation  provides 
the  basic  structure  presented  by  the  Application  Engineering  Envi¬ 
ronment.  You  may  also  want  to  implement  other  structures  that 
help  application  engineers  locate  and  evaluate  components.  For 
example,  if  your  tools  include  database  facilities,  you  can  provide 
alternate  indexes. 

-  Identify  the  tools  that  the  targeted  project  has  decided  to  use  as 
part  of  Application  Engineering.  Make  them  part  of  the 
Application  Engineering  Environment,  where  possible. 


3.2  Risk  Management 

Itisk  The  procedures  desaibed  in  the  Application  Engineering  User’s  Guide  will 

be  hard  to  follow  (i.e.,  vague,  incomplete). 

Implication  Application  engineers  will  have  a  difficult  time  reusing  work  products.  This 

may  cause  excessive  use  of  the  projea  support  staff.  It  may  also  cause 
application  engineers  to  favor  creating  work  products  from  scratch  rather  than 
reusing  existing  work  products. 

Mitigation  Review  the  Process  Support  documentation  with  application  engineers  to  see 

what  areas  of  the  process  are  incomplete,  inconsistent,  or  ambiguous.  Have 
them  generate  example  work  products,  noting  where  they  misinterpret  or 
misuse  the  documentation. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 

Contingency  The  Process  Requirements  work  product  is  incomplete,  ambiguous,  or 

inconsistent. 

Source  Process  Requirements  Activity 

Response  Describe  specifically  where  the  Process  Requirements  work  product  is 

inadequate  and  suggest  improvements.  Proceed  with  the  implementation  of 
Process  Support  as  far  as  possible  while  the  Process  Requirements  are  being 
updated. 
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The  Generadon  Procedure  cannot  be  used  in  its  current  form  in  the 
^){dication  Engineering  process. 

Generation  Implementation  Activity 

Describe  how  the  Generation  Procedure  needs  to  be  changed  so  that  it  will  fit 
within  the  ^^cation  Engineering  process. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Apf^cation  Engineering  process  is  difficult  to  use  or  is  too 

labor-intensive. 

Sowu  Project  Support  Activity 

Response  Identify  where  the  problems  exist  and  discuss,  with  the  application  engineers, 

ways  of  redudng  (or  eliminating)  these  problems  (e.g.,  throu^  the  use  of 
automation). 
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1.  GETTING  STARTED 

The  Project  Support  Activity  is  an  activity  of  Domain  &igmeering  for  validating  Apj^cation  Engineering 
Process  Support  and  assisting  projects  in  its  use.  ^plication  Engineering  Process  Support  (AEPS) 
is  the  application  engineering  name  for  the  Domain  Implementation,  lb  ensure  that  the  baselined  Do¬ 
main  Implementation  is  usable  and  effective,  Project  Support  indq>endently  validates  it  from  the  per¬ 
spective  of  the  product  and  process  needs  of  the  targeted  application  engineering  project  Project  Sup¬ 
port  assists  application  engineers  in  effective  use  of  the  process  and  supporting  materials,  throu^ 
delivery  and  installation,  and  consultation  for  the  targeted  project.  Project  Support  answers  questions 
about  the  process,  its  documentation,  and  its  automation.  Based  on  issues,  problems,  and  future  needs 
identified  by  application  engineers.  Project  Support  coordinates  feedback  to  the  rest  of  Domain  Engi¬ 
neering  for  improvements  in  the  supported  process  or  products  of  application  engineering.  The 
Project  Support  Activity  is  performed  for  each  work  product  family  in  the  domain. 

1.1  Objectives 

The  objectives  of  the  Project  Support  Activity  are  to: 

•  Evaluate  the  effectiveness  and  quality  of  Domain  Implementation  for  use  by  the  targeted 
application  engineering  project 

•  Provide  customer  support  to  the  targeted  application  engineering  project  in  the  understanding 
and  use  of  Domain  Implementation 

•  Provide  a  conduit  by  which  the  needs  of  the  targeted  application  engineering  project  can 
influence  domain  improvements  and  evolution 

1.2  Required  Information 

The  Project  Support  Activity  requires  the  following  information: 

•  Domain  Definition 

•  Domain  Implementation 

13  Required  Knowledge  AND  Experietice 

The  Project  Support  Activity  requires  domain  and  software  knovdedge  and  e]q)erience  in: 
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•  The  methods,  practices,  and  solutions  of  aj^cation  develofxnent  in  the  targeted  {H’oject 

•  Installing  and  evaluating  software  products  and  their  documentation 

•  Assisting  engineers  and  managers  in  the  use  of  jvocess  documentation  and  automation 

2.  PRODUCT  DESCRIPTION 

The  Project  Support  Activity  produces  no  work  products.  Instead,  it  is  a  service  activity  to  the  targeted 
application  engineering  in-oject. 

3.  PROCESS  DESCRIPTION 

The  Project  Support  Activity  consists  of  two  steps  shown  Figure  DE.4-1.  The  first.  Domain  Widation, 
is  ongoing  and  must  certify  each  baseline  Domain  Implementation  as  it  becomes  available.  The  se¬ 
cond,  Domain  Delivery,  is  initiated  at  the  beginning  of  each  targeted  application  engineering  project 
and  continues  until  that  project’s  termination. 


t  A:tivity  performed  once  for 
each  work  product  family  in 
the  Domain  Implementation 


figure  DE.4-1.  I^ojectSup^xxtlVocess 


3.1  Procedure 

Follow  these  steps  for  the  Project  Support  Activify. 

Step:  Domain  Validation  Activity 

Action  Certify  that  baselined,  deliverable  Domain  Implementation  for  the  work 

product  family  will  satisfy  the  targeted  apjdication  engineering  project’s 
needs,  as  specked  in  the  Domain  Definition  (available  in  future  releases). 

Input  •  Domain  Definition 

•  Domain  Implementation 

BesuU  None 

Heuristics  •  Review  the  Domain  Plan  and  Domain  Definition  from  the  perspective  of 

the  targeted  application  engineering  project,  ^isure  that  the  product  and 
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fx-ocess  needs  of  the  targeted  project  are  {xoperly  reix-esented.  Advise  the 
rest  of  Domain  Engineering  on  the  realistic  product  and  process  needs  of 
the  targeted  application  engineering  project. 


•  Perform  an  independent  evaluation  of  eadi  baseline  of  the  Domain 
Implementation  as  it  becomes  available.  Evaluate  whether  it  properly  sat¬ 
isfies  and  balances  the  intended  mix  of  general  business  objectives  and 
specific  application  engineering  project/customer  needs. 

•  Perform  independent  validation,  including  extensive,  scenario-based 
testing  of  the  (integrated)  Product  Implementation  and  ^plication  Engi¬ 
neering  Environment  portions  of  the  Domain  Implementation  baseline. 
Evaluate  the  correctness  and  usability  of  the  Application  Engineering 
User’s  Guide  as  it  relates  to  use  of  the  Product  Im^ementation  and  Ap¬ 
plication  Engineering  Environment. 


•  Attempt  to  build  typical  products  that  reflect  realistic  project  experience 
on  existing  ^tems  in  the  domain.  Identify  capabilities  or  characteristics 
of  those  products  that  the  Domain  Definition  accommodates  but  that  are 
not  attainable  with  the  provided  Domain  Implementation  baseline. 


•  Evaluate  the  impact  of  the  Domain  Implementation  baseline  on  the 
efficiency  and  effectiveness  of  the  targeted  application  engineering  proj¬ 
ect.  Identify  improvements  in  realistic  and  practical  Domain 
Implementation  usability. 

Step:  Domain  Delivery  Activity 


Action 


Input 

Result 

Heuristics 


Deliver  Domain  Implementation  to  the  targeted  application  engineering 
project,  assist  with  its  use,  and  identify  needed  prcxluct  or  prcx:ess 
improvements  (available  in  future  releases). 

Domain  Implementation 

None 

•  Initiate  an  instance  of  this  activify  at  the  beginning  of  each  targeted 
application  engineering  project;  continue  this  activity  until  the  project  ter¬ 
minates. 

•  Provide  copies  of  (xocess  documentation  (i.e.,  the  implication  Engineering 
User’s  Guide)  to  the  engineers  and  managers  of  the  ai^lication 
engineering  project. 

•  Install  the  A{^lication  Engineering  Bivironment  (and  subsequent 
upgrades),  including  the  Adaptable  Components  from  the  Prcxluct 
Implementation,  for  project  use  and  cdieck  it  for  proper  operation. 

•  Explain  use  of  the  Application  Engineering  User’s  Guide  for 
understanding  and  performing  the  prcx%ss  of  developing  draft  application 
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engineering  work  products.  Ejqilain  the  use  of  the  ^plication 
Engineering  Enviroiunent  as  described  in  the  User's  Guide. 

•  Provide  consultation  services  to  api^ication  engineers  as  they  perform 
Application  Engineering.  Consulting  requires  extensive  domain  knowl¬ 
edge  to  answer  application  engineers’  questions  accurately  and  fully.  Con¬ 
sultants  should  be  knowledgeable  in  aspects  of  Domain  Implementa¬ 
tion.  There  also  needs  to  be  a  core  of  expert  consultants  ^o  are 
sufficiently  familiar  with  other  domain  engineering  work  products  to  pro¬ 
vide  complete,  detailed,  in-depth  information,  rationales,  and  assistance 
when  complex  problems  are  encountered  by  a  project.  In  small  organiza¬ 
tions,  the  entire  domain  engineering  team  may  be  c^led  on  as  a  consulting 
resource. 

•  In  response  to  the  delivery  services  provided,  application  engineers  will 
identify  problems,  improvements,  and  future  needs  that  Domain  Engi¬ 
neering  should  consider  for  possible  action.  Some  of  these  ideas  will  relate 
directly  to  meeting  customers’  needs  while  others  will  relate  to  how  effi¬ 
ciently  application  engineers  can  use  the  process  and  associated  domain 
assets.  Properly  record  and  communicate  these  ideas  and  their  motiva¬ 
tions  to  the  rest  of  Domain  Engineering  as  feedback  from  application  engi¬ 
neering.  This  is  a  key  part  of  Project  Support  and  is  essential  to  continual 
project  responsive  improvement  of  a  domain. 

3.2  Risk  Management 

Risk  The  needs  of  a  particular  application  engineering  project  will  conflict  with  a 

simple  interpretation  of  prescribed  standards  and  procedures. 

Implication  The  project  will  be  forced  to  work  in  conflict  with  that  interpretation  and  to  be 

less  effective  and  efficient. 

Mit^aRon  Ify  to  interpret  standards  and  guidelines  flexibly  so  that  they  best  fit  the  needs 

of  the  targeted  project.  Be  aware  of  variations  in  the  Process  Support, 
particularly  in  environment  installation,  that  support  different  needs.  Ihilor 
consultation  to  the  targeted  project’s  needs. 

Risk  Changes  in  the  circumstances  of  a  project  may  conflict  with  the  previous 

interpretation  of  prescribed  standards  and  procedures. 

Implication  The  project  will  be  forced  to  work  around  obsolete  support  and  will  be  less 

effective  and  efficient  than  necessary. 

Actuation  Reconsider  the  support  given  to  a  project  whenever  circumstances  diange 

significantly.  Be  prepared  to  adjust  the  environment  and  consulting  advice  to 
fit  current  needs  better. 
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4.1  Feedback  TO  Information  Sources 

CotaUigenqf  Aj^lication  engineers  are  having  difficulty  using  the  ^)plication  Engineering 

process  or  Domain  Implementation  to  develop  draft  work  jH'oducts. 

Source  Process  Support  Development  Activity 

Refuse  •  Suggest  better  ways  to  the  project  for  performing  the  process  within  the 

prescribed  standards. 

•  Document  the  nature  of  the  difficulties  and  suggest  im|»'ovements  in  the 
presaibed  process  or  in  its  documentation  or  automation. 

Contingent  Particular,  noncommon  customer  requirements  cannot  be  oppressed  in  an 

Application  Model. 

Sourte  •  Domain  Definition  Activity 

•  Process  Requirements  Activity 

•  Process  Support  Development  Activity 

Re^onse  •  Identify  unrecognized  domain  variations  that  application  engineers  need. 

•  Suggest  to  the  project  how  it  can  best  work  around  current  limitations. 

4.2  Feedback  From  Product  Consumers 
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AE.  APPLICATION  ENGINEERING  OVERVIEW 

1.  GETTING  STARTED 

A{)ptiaition  Engineering  is  a  Synthesis  [vocess  for  creating  and  supporting  an  apjdication  product  that 
satisfies  spedfied  customer  requirements.  A  product  is  refx^esent^  by  a  set  of  assodated  work  prod¬ 
ucts  that  result  from  analysis  of  those  requirements.  .^>plication  Engineering  is  characterized  by  a 
comprehensive  life-t^de  process  for  the  management,  analysis,  production,  and  support  of  a  product 
as  a  set  of  work  products  that  offer  opportunities  for  reuse. 

In  an  organization  practidng  opportunistic  Synthesis,  the  Application  Engineering  process  combines 
activities  that  create  work  products  from  saatdi  with  activities  that  reuse  existing  work  products,  in 
whole  or  in  part,  available  from  ^plication  Engineering  Process  Support.  Activities  involving  reuse 
focus  on  application  engineers  resolving  standardized  dedsions  relating  to  the  work  product  to  deter¬ 
mine  whether  members  of  existing  work  product  families  will  satisfy  Application  Engineering  needs. 
Based  on  these  dedsions,  application  engineers  obtain  useful  work  products  from  Application  Engi¬ 
neering  Process  Su{^rt  and  t^or  them  into  work  {X’oducts  that  comfdetely  meet  customer  requirements. 

1.1  Objectives 

The  objectives  of  Application  Engineering  are  to: 

•  Understand  the  needs  of  customers,  balandng  concerns  of  cost  versus  value,  to  produce  a 
product  that  fulfills  those  needs  most  effectively 

•  Organize  and  direct  resources  for  the  production  and  support  of  the  product 

•  Produce  software  and  documentation  that  support  the  delivery  and  use  of  the  product 

•  Maximize  productivity  in  creating  work  products  through  aj^ropriate  use  of  reusable 
components  provided  by  ^>plication  Engineering  Process  Support 

1.2  Required  Information 

^yplication  Engineering  requires  the  following  information: 

•  Application  Engineering  Process  Support 

•  Customer  requirements 

L3  Required  Knowledge  AND  Experience 

Application  Engineering  requires  domain,  business,  and  software  knovdedge  and  experience  in: 
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•  The  problems  that  the  products  in  the  domain  are  intended  to  solve  and  the  engineering 
tradeoffs  to  be  considered  in  seating  a  viable  solution 

•  Understanding  and  interpreting  customer  requirements  and  developing  applications  that 
satisfy  those  requirements 

•  The  management,  production,  and  delivery  of  software  work  products 

•  How  to  use  the  ^plication  Engineering  Process  Support  to  develop  an  application 

•  The  information  required  by  the  Application  Engineering  process  employed  by  the  project 

2.  PRODUCT  DESCRIPTION 

The  product  of  Application  Engineering  is  a  set  of  work  products  as  determined  by  the  process  being 
followed.  Projects  use  their  organization’s  normal  softwue  development  process  producing  familiar 
work  products.  Among  the  work  products  that  an  Api^cadon  Engineering  process  might  produce  are 
software  requirements  documents,  software  system  ardiitectures,  and  so^are  partitioned  into  sepa¬ 
rately  developed  components. 

3.  PROCESS  DESCRIPTION 

The  ^){dication  Engineering  Activify  consists  of  a  set  of  activities  specific  to  the  software  develoi»nent 
process  your  organization  uses.  You  perform  the  same  set  of  activities  whether  or  not  you  practice  op- 
portum'stic  Ifynthesis.  Within  activities,  however,  you  seek  opportunities  to  reuse  existing  work  prod¬ 
ucts;  thus,  how  you  perform  activities  may  differ  when  you  incorporate  opportum'stic  Synthesis  into 
your  software  development. 

Figure  *£-l  shows  an  ESP-derived  and  protofypical  process  for  Application  Engineering.  It  is 
recog^jzable  as  a  conventional  waterfall  software  development  process  and  therefore  straightforward 
to  tailor  to  the  needs  of  your  organization.  Reuse  within  this  process  is  entirely  localized  to  focus  on 
rapid  production  of  draft  individual  application  engineering  work  products. 

The  activities  of  the  Application  Engineering  process  are  organized  into  three  classes.  (In  the  ESP  model, 
activities  are  grouped  into  subdasses,  and  the  subdasses  are  grouped  into  dasses.)  The  classes  are  as 
follows: 

•  Project  Managment.  These  management  and  administrative  activities  support  planning, 
monitoring,  and  controlling  the  project.  These  activities  indude  the  following: 

-  Plan  and  initiate  those  activities  required  to  initially  start  the  project,  produce  the 
project’s  master  plan  and  sdiedule,  estimate  overall  cost,  and  acquire  necessary 
resources. 

-  Determine  the  objectives,  alternatives,  constraints,  and  success  criteria  for  a  tyde. 

-  Analyze  the  risks  inherent  in  the  cycle’s  objectives  and  suggest  risk  aversion  strategies. 

-  Produce  the  Cyde  Development  Plan  \diidi  organizes  and  provides  the  details  for  the 
activities  which  will  be  performed  during  the  <yde. 
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-  Initiate  the  cyde  development  activities  and  ctoscr/t  the  project’s  jx’ogress  and  current 
status. 

•  Process  Managmau.  These  activities  manage  the  tedmical  control  and  quality  of  the  delivered 
product.  These  activities  indude  the  foUoudng: 

-  Define  quality  standards  and  ensure  that  the  work  products  oonfmn  to  these  standards. 

-  Assess  the  project’s  current  process,  identify  areas  that  need  {process  improvement, 
and  improve  the  process. 

-  Baseline  each  inaement  of  the  product(s)  and  control  any  dianges  to  the  product(s). 

-  Control  the  editing,  production,  and  distribution  of  project  documentation. 

-  Create  and  maintain  the  software  systems  that  the  apf^cadon  engineers  use  to  devdop 
and  test  the  product(s). 

-  Develop,  validate,  and  administer  the  training  program  for  the  developers  and  users 
of  the  system. 

•  Product  Devdopment.  Activities  in  this  class  spedfy,  design,  implement,  verify,  and  maintain 
the  end  product.  Product  Development  consists  of  the  following  activities  and  subclasses: 

-  Software  Systems  Et^fneerir^.  Activities  in  this  subdass  provide  the  ^tern’s  specification 
and  design.  It  consists  of  the  following  activities: 

—  Define  System  Requirements.  This  activity  collects,  integrates,  specifies,  relates, 
and  organizes  the  project’s  needs  and  objectives  to  provide  the  foundation  for 
system  design  and  implementation.  These  needs  and  objectives  are  expressed 
in  the  system  requirements. 

—  Develop  System  Architecture.  This  activify  identifies  a  ^tem-level 
architecture,  including  hardware  and  software  components,  that  satisfies  the 
system  requirements  within  budget  and  schedule  constraints.  It  documents 
this  architecture  in  the  system  architecture. 

-  Software  Er^iaeerir^.  This  subdass  indudes  all  activities  related  to  software  requirements, 
software  design,  and  software  implementation: 

—  Requirements,  This  activity  analyzes  the  ^tem  requirements  and  architecture 
to  derive  software  requirements  that  further  darify  the  allocated  system 
requirements. 

—  Architecture  Dedgn.  This  activify  derives  a  software  fystem  configuration  that 
performs  the  required  functions  at  the  necessary  level  of  performance  and 
reliat^fy.  This  omfiguratkxi  is  documented  in  the  strftware  fyston  ardiitecture. 

—  Component  Des^.  This  activify  refines  the  software  system  ardiitecture  to 
identify  the  lowest  level  components  and  their  interfaces.  It  produces  a 
detailed  design  document,  the  Component  Design. 
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—  Ovate  Cbii^poiimtf.lliis  activity  devel<^aiKl  documents  the  source  oocte  for 
each  softwue  component  in  accordance  with  the  detailed  design  inovided  in 
Component  Design. 

—  InUffrate  Software  Components.  This  activity  integrates  the  software 
components  into  larger  software  configuration  items  through  an  inaemental 
process  of  adding  software  components  to  grow  the  core  of  software  into  the 
finished  system. 

-  Product  Vetipcathn  and  Validation.  This  subclass  includes  all  activities  related  to  the 
verification  and  validation  of  the  system  and  software  requirements. 

—  Vaify  Software  Components.  This  activity  verifies  the  software  components. 

—  Verify  Software  Integration.  This  activity  verifies  the  integrated  software 
components  up  to  the  final  tystem. 

-  Operation  and  Maintenance.  This  subclass  includes  all  activities  related  to  system 
installation  and  operational  support. 

Provide  Operational  Support.  This  activity  provides  technical  assistance  in  re¬ 
sponse  to  customer  requests  and  performs  regular  maintenance  to  ensure 
that  the  finished  system  performs  efBdently. 

For  brevity,  this  process  concentrates  on  software  products,  omitting  supporting  deliverables  (e.g., 
user  manuals).  A  complete  process  would  show  supporting  deliverables  and  the  activities  that  produce 
them. 

3.1  Procedure 

In  this  opportunistic  ^thesis  process,  reuse  occurs  while  performing  certain  i^)plication  Engineering 
activities — specifically,  those  yielding  work  products  for  wMch  Domain  Engineering  has  implemented 
application  engineering  work  product  families.  Thus,  application  engineers  perform  the  activities  of 
the  process  shown  in  Figure  AE-1. 

The  way  each  activity  is  performed  depends  in  part  on  whether  Domain  Engineering  has  provided 
work  product  families  that  support  reuse  within  that  activity.  The  consequences  of  Domain  Engineer¬ 
ing  support  for  opportunistic  reuse  are  described  in  the  following  five  representative  steps  for  creating 
a  work  product.  An  application  engineer  performs  these  steps  to  create  a  work  product  whether  or 
not  reuse  is  supported.  However,  when  reuse  is  supported,  application  engineers  perform  these  five 
steps  somewhat  differently.  The  heuristics  for  each  step  include  descriptions  of  differences  due  to 
reuse. 

Step:  Define  Success  Criteria  for  the  Work  Product 

Action  Determine  the  success  CTiteria  and  characteristics  that  the  work  product  must 

have  to  be  considered  complete. 

Input  Required  information  of  the  application  development  process  relevant  to  the 

work  product.  This  information  would  indude  customer  requirements  or 
appropriate  work  products  from  preceding  activities. 
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Result  Success  criteria 

Heuristics  •  Review  the  company’s  policies  and  procedures  to  determine  the 

requirements  and  restrictions  relevant  to  this  particular  type  of  work  fvod- 
uct.  Define  your  success  oiteria  as  meeting  relevant  pdides  and  {x-ocedures. 

•  Review  customer  requirements  or  appropriate  work  products  fi'om 
preceding  activities  to  determine  the  success  criteria  relevant  to  this  partic¬ 
ular  type  of  work  {^odud.  Define  your  success  criteria  as  meeting  relevant 
customer  requirements. 

•  Determine  reviewers  of  the  work  product  who  can  provide  insights  and 
alternative  viewpoints  relevant  to  the  work  product’s  subject  matter. 

Step:  Develop  Internal  Structure 

Design  the  internal  structure  of  the  work  product  based  upon  the  needs  of  the 
application  engineering  project. 

•  Success  CTiteria 

•  Application  Engineering  Process  Support:  User’s  Guide  for  the  type  of 
work  product 

Work  product’s  internal  structure 

•  Select  from  the  work  product  families  (desaibed  in  the  User’s  Guide)  for 
an  existing  family  that  might  directly  contribute  to  this  activity’s  work  prod¬ 
uct.  For  example,  if  you  are  producing  a  requirements  specification  docu¬ 
ment,  search  for  a  requirements  specifications  document  family  that  could 
be  used  in  producing  the  new  specification. 

•  The  internal  structure  depends  upon  the  work  product  type.  For  a 
document,  this  might  be  an  outline;  for  a  plan,  a  set  of  milestones;  for 
source  code,  an  internal  design. 

•  If  you  cannot  find  a  suitable  member  of  the  work  product  family,  you  must 
create  the  structme. 

•  Modify  or  extend  the  structure  to  suit  specific  needs. 

Step:  Produce  the  Work  Product 

Action  Produce  the  work  product  by  filling  in  its  internal  structure. 

Input  •  Success  Criteria 

•  Application  Engineering  Process  Support:  User’s  Guide  for  the  type  of 
work  product 

•  Work  product’s  internal  structure 


Action 

Input 

Result 

Heuristics 
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Heuristics  •  The  User's  Guide  desaibes  a  procedure  for  creating  an  >^plication 

Model  (i.e..  Application  Modeling).  This  procedure  identifies  what  ded- 
sions  to  make  and  how  to  apply  those  decisions  to  select  a  member  of  the 
work  product  family. 

•  Develop  the  desired  work  product  by  applying  the  decisions  of  the 
Application  Model  to  select  and  tailor  work  product  component  families 
into  components  that  fill  in  parts  of  the  work  product’s  internal  structure. 

•  If  you  cannot  find  suitable  component  family  members,  you  must  create 
the  work  product. 

Step:  Verify  the  Work  Product 

Aaion  Verify  that  the  work  product  meets  the  success  criteria. 

Input  •  Work  product 

•  Success  criteria 

Result  None 

Heuristics  For  each  success  criterion,  determine  whether  the  completed  draft  of  the  work 

product  satisfies  the  success  criteria.  If  it  does  not,  alter  the  draft. 

Step:  Baseline  the  Work  Product 

Action  Provide  a  copy  to  configuration  management  for  baselining.  Produce  the 

necessary  reports  characterizing  the  work  product  and  its  cost. 

Input  Work  product 

Result  None 

Heuristics  Include  information  in  standardized  reports  characterizing  the  extent  that 

work-product  reuse  occurred,  lb  the  extent  possible,  tell  the  domain  engineers 
what  Unds  of  work  product  components  were  needed  and  not  found,  or  will 
be  needed  in  the  subsequent  (follow-on)  activities  of  this  particular 
application  project. 

3.2  Risk  Management 

The  risks  associated  with  Application  Engineering  depend  on  the  specific  software  development 
process  followed  by  the  application  engineers.  Nonetheless,  the  following  risks  are  (more  or  less) 
independent  of  the  particular  Application  Engineering  process. 

Application  engineers  will  select  totally  inappropriate  (unknown  to  them) 
members  of  a  work  product  family. 
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Modifying  or  extending  the  selected  family  member  so  that  it  suits  the 
application  engineer’s  needs  will  be  time-consuming,  thereby  making  the  cost 
of  developing  a  work  product  more  expensive  than  developing  it  from  saatch. 

Have  the  Project  Support  staff  initially  work  together  with  the  application 
engineers  to  help  them  understand  how  to  effectively  express  their  needs  in  an 
Application  Model. 

Application  engineers  will  inadvertently  invalidate  certain  desired  properties 
of  a  family  member  when  they  modify  or  extend  the  member  to  suit  their 
needs. 

Work  product  verification  costs  will  inaease  because  application  engineers 
will  have  to  perform  more  extensive  testing  than  normally  necessary  to  ensure 
that  all  properties  of  the  family  member  are  still  valid. 

Have  the  Project  Support  staff  available  to  review  the  impact  of  proposed 
modifications  or  extensions  not  addressed  in  the  User’s  Guide. 


4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 


Contingency 


Source 

Response 


Contingency 


Source 

Response 


Contit^ency 


Application  Engineering  Process  Support  does  not  provide  the  information 
needed  to  decide  which  families  and  which  components  are  useful. 
Consequently,  application  engineers  do  not  find  reusable  components  or 
spend  excessive  time  finding  them. 

Domain  Engineering 

•  Request  immediate  (verbal)  clarification  from  the  project  support  staff. 

•  Characterize  the  additional  information  needed  to  assess  the  reuse  potential 
of  a  family  and  its  members.  Proceed  with  the  Application  Engineering 
process  using  the  implication  Engineering  Process  Support  to  the  extent 
possible  given  the  inadequades. 

Application  engineers  are  unable  to  identify  work  products,  within  the 
domain,  that  are  relevant  to  the  current  application  development  project. 

Domain  Engineering 

•  Identify  what  kinds  of  families  need  to  be  developed. 

•  Proceed  with  the  ^plication  Engineering  process  using  the  Application 
Engineering  Process  Suj^rt  to  the  extent  possible  given  the  inadequades. 

The  Application  Engineering  Process  Support  provided  is  incomplete  or 
defident. 
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4.2  Feedback  From 

Contingency 

Source 

Response 

Contingency 

Source 

Besponse 
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Describe  the  inadequacies  in  the  Application  Engineering  Process  Suj^it. 
Indicate  wdiich  sections  are  incomplete  or  defident.  These  may  indude: 
missing  work  product  families,  an  incomplete  User’s  Guide,  errors  in  the 
User’s  Guide,  improperly  described  Adaptable  Components,  malfunctioning 
generation  procedure(s),  and  bugs  in  interface  software  provided  by  Domain 
Engineering. 

Product  Consumers 

The  customer  requests  new  or  modified  capabilities  for  the  system. 
Customer 

•  Build  a  new  version  of  the  system. 

•  Reject  the  suggestions  as  out  of  scope. 

The  customer  identifies  system  anomalies,  changes  to  the  target  environment, 
inadequate  system  performance,  or  inadequate  reliability. 

Customer 

•  Correct  system  anomalies,  accommodate  changes  to  the  target 
environment,  tune  the  system. 

•  Reject  changes  as  out  of  scope. 

•  Ask  Domain  Engineering  to  make  necessary  changes  in  the  domain. 
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OV.  OVERVIEW  OF  A  LEVERAGED  SYNTHESIS 

PROCESS 


This  part  of  the  guidebook  [H'esents  a  leveraged  ^thesis  process.  This  is  a  process  suitable  fiv  an 
organizati<Hi  that  has  targeted  the  goals  associated  with  the  leveraged  stage  of  reuse  capability,  as  de¬ 
fined  by  the  RCM.  lb  help  you  luiderstand  whether  a  leveraged  process  suits  your  organization,  this 
section  discusses  the  assumptions  that  underlie  the  |vocess  and  the  nature  of  software  devdc^xnent 
vdMn  u«i%  the  process. 

L  UNDERLYING  ASSUMPTIONS 

The  RCM  defines  four  stages  of  reuse  capability  imfdementation  and  characterizes  each  stage  by  a 
set  of  goals.  The  leveraged  Synthesis  process  describi^  in  this  part  of  the  guidebook  was  desigiwd  to 
fit  the  goals  associated  with  the  leveraged  stage  as  described  in  the  Fundamentals  section  of  the  over¬ 
view  to  this  guidebook  (Section  OV2) .  lb  adopt  this  process,  an  organization  must  have  targeted  those 
goals  as  a  minimum.  Your  organization  may  dioose  to  adopt  the  leveraged  process  even  if  it  has  the 
potential  to  attain  goals  associated  with  the  more  advanced  anticipating  stage  oi  reuse  capability  im- 
jdementation.  However,  this  [Mrocess  does  not  depend  upon  nor  require  your  organization  to  attain 
aity  of  the  more  ambitious  goals  assodated  with  ^e  anticipating  stage. 

The  goals  associated  with  the  leveraged  stage  introduce  requirements  for  a  process  to  be  used  Ity 
organizations  targeting  that  stage.  The  Synthesis  process  described  in  this  part  the  guidebook  is  one 
example  of  a  process  that  an  organization  targeting  the  leveraged  stage  could  adopt  It  differs  from 
otho'  sudi  processes  because  it  reflects  assunq>tions  about  an  oiganizatkm's  circumstances  that  ex¬ 
tend  those  imidied  Ity  the  RCM  goals  for  the  lever  a^  stage.  Section  23  in  Fkrt  ^  oi  the  guidebo(dc 
describes  characteristics  common  to  all  ^thesis  {vocesses,  particularly  that  the  process  conqmses 
iteratively  cooperating  Domain  Engineering  and  Apfdication  Engineering  sul^ocesses.  Additional 
assumptions  that  distinguish  the  leveraged  Synthesis  {vocess  are  as  follows: 

•  Assigned  managers  and  engineers  have  sufficient  knowledge  md  expaUst  im  tite  domaiH.  This 
assumption  meam  that  butiness-area  managraient  is  willing  and  aide  to  cmnniit  people  to  this 
endeavor  who  have  the  needed  knovdedge  and  expertise  to  ensure  its  success.  The  people  as¬ 
signed  are  the  experts  in  this  business  area;  th^  understand  both  tiieNdiys’  and  *hows’  (rf  the 
existing  tystems  and  work  products  upcm  wfakfa  the  domain  is  based,  lliey  also  understand  the 
future  of  the  business  area  and  the  organization’s  objectives  tof  it 

•  ne  rok  of  Domain  Engineering  is  to  standari^  tike  pmetko  ofAppiieatUm  Engineering.  Tl^ 
assumption  means  first,  that  Domain  Ei^eering  standardizes  ^  scope  of  the  domain  to  a 
specified  product  frunily.  Each  member  this  frunity  is  a  product  (Le.,  a  s(tftware  tystmn  and 
all  assodated  wtxk  products)  tiiat  the  oiganfratioa  win  be  dde  to  produce  for  a  given  customer. 
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Secondly,  it  means  that  Domain  Engineerii^  ocmcurrently  engineers  a  standardized  process  oi 
Application  Ei^eering  that  is  tailored  to  the  effective  and  efiSdent  production  of  individual 
products,  lb  the  degree  that  the  {vocess  can  be  made  more  effective  or  efficient.  Domain 
Engineering  may  enhance  it  with  automated  support.  Business  objectives  act  as  constraints 
that  limit  the  scope  of  the  domain,  making  process  and  product  family  standardization  feaaUe. 

•  Institu^  a  standardiziedAppliaaionEng^neainginveets  requires  DomauiEKgfKeerii^  to  si^iort 
projects  with  automation,  doeumentatton,  training,  and  consulting.  Domain  Engineering  supports 
application  engineering  projects  not  only  by  (voviding  them  with  ai^ropriate  reusable  assets 
but  also  by  supporting  their  overall  effort  to  produce  a  customer  product  with  those  assets. 
Domain  Engineering  {vovides  automated  support  for  the  prescribed  ^plication  Engineering 
process;  documents  the  process  sufficiently  for  effective  use;  provides  training  in  efficient  use 
of  the  process;  and  consults  with  eadi  fHOject  on  how  best  to  use  the  process. 

•  Raise  focuses  on  system-level  variations  in  problems  and  solutions.  Standardization  of  a  product 
family  involves  the  identification,  preferably  at  the  system-level  for  nuudmum  leverage,  of 
commonalities  and  variations  that  characterize  such  products.  Commonalities  provide  the  ba¬ 
sis  for  potential  leverage  but  depend  on  accommodation  of  variations  for  sufficient  flexibility. 
Variations  correspond  to  either  problem-level  or  solution-level  dedsions  that  application  en¬ 
gineers  need  to  make  in  order  to  produce  a  particular  product.  The  essence  of  the  >^plication 
Engineering  process  is  making  and  evaluating  required  decisions  and  using  those  decisions  in 
mechanically  generating  corresponding  work  products. 

•  An  effective  domain  depends  on  consistera  objectives  and  schedules  which  reguires  coorttiruded 
pUuuungandsttffpngofdomaan  engjneeringand  application  a^Jneering projects.  H’aditionally,  ap¬ 
plication  engineering  projects  have  operated  autonomously  and  in  isolation  from  similar  proj¬ 
ects.  This  assumption,  in  contrast,  means  that  projects  are  viewed  as  agents  of  a  domain.  Proj¬ 
ects  attempt  to  satisfy  customer  needs  by  projecting  the  capabilities  supported  by  the  domain 
and  stimulating  domain  evolution  when  the  domain  is  inadequate.  Project  staffing  comes,  at 
least  partially,  by  allocation  fr'  «m  the  resources  of  the  domain.  Conflicting  needs  of  a  project 
with  Domain  Engineering  objectives  or  sdiedule,  or  with  other  projects,  must  be  resolved 
through  coordinated  management  of  the  domain. 

•  Domain  viability  depends  on  iterative  domain  evolution.  A  viable  domain  is  one  that  supports 
rapid  delivery  of  high-quality  products  that  meet  customer  needs.  Since  customer  ne^  are 
diverse  and  changing,  as  is  technology,  the  domain  must  evolve  to  reflect  those  changes.  The 
jximaiy  insights  for  domain  evolution  come  as  a  result  of  initiation  of  projects  for  new  custmners 
and  feedback  from  «dsting  projects. 

2.  SOFTWARE  DEVELOPMENT  WITH  A  LEVERAGED  SYNTHESIS  PROCESS 

This  section  is  a  general  overview  of  the  leveraged  Synthesis  process  presented  in  this  part  of  the 
guidebook.  It  gives  an  overall  feel  for  software  development  and  management  as  practiced  by  an  orga¬ 
nization  with  leveraged  reuse  capabilities,  without  elaborating  every  activity  or  every  possible  varia¬ 
tion  or  interpretation  of  the  process.  As  Figure  OVJ2-1  in  Part  Syn  depicts,  Domain  Engineering  and 
Application  Engineering  activities,  and  the  interactions  between  them,  are  defining  aspects  of  any 
Synthesis  process.  This  section  describes  this  leveraged  Synthesis  process  from  three  perspectives: 
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•  A  business^u’ca  (wganizatkMi,  ti^iicfa  enocMnpasses  a  (kunain  engjineering  groiq>  and  one  or 
more  apfdication  engineering  projects 

•  Adomainei%ineeringgiroup,v^ikfa  is  respcmsflde  for  process  and  product  Camifystandardizatkm 
across  a  domain 

•  An  api^icadon  engineering  project,  ^ch  is  responsible  for  producing  and  delivering  a  system 
to  a  particular  customer 

This  section  condt^es  with  abrief  scenario  of  how  Domain  Engineering  and  Apj^cation  Engineering 
might  Really  work  and  interact. 

2.1.  ORGANIZAIIONALPERSPBCnVE 

In  leveraged  ^thesis,  a  business-area  oiganizatitm  sets  eaqilidt,  kmg-term  objectives  that  direct  capital 
investment  in  jvocess  and  product  standardization.  The  scope  of  this  investment  is  a  family  systems 
that  represents  the  strat^c  focus  of  the  organization.  This  scope  indicates  the  organization’s  market, 
or  customer  base,  vriiere  it  ea^xicts  to  find  its  future  business  opportunities.  Reuse  at  the  leveraged 
stage  is  a  key  medianism  for  attaining  strategic  business-area  or  organizational  mission  objectives. 

Within  this  framework,  a  domain  is  the  organizational  vehicle  for  all  domain-specific  software 
development  vriiich  indudes  both  Domain  Engineering  and  ^>plication  Engineering  efforts  (see  Fig¬ 
ure  OV-1).  Domain  Engineering  focuses  on  develojnng,  instituting,  and  evolving  effective  {vocess/ 
product  standardizatitm  suited  to  the  needs  of  the  business.  Client  application  engineering  fvojects 
are  formed  in  the  domain  vriienever  appropriate  opportunities  arise  to  build  systems  that  fall  within 
the  domain’s  scope.  As  the  organization  recognizes  dianging  customer  needs  or  technology,  Donudn 
Engineering  evolves  the  domain  to  reflect  those  changes. 

The  benefit  of  this  approadi  is  higher  application  engineering  productivity,  accompanied  by  noore 
predictable  sdiedules  and  costs,  more  con^tent  quality  in  the  product,  and  more  rapid  responses  to 
diverse  and  changing  customer  needs.  Domain  Engineering  funding  will  usually  come  from  a  com¬ 
bination  of  organizational  capital  and  client  project  receipts.  The  guiding  prindple  is  tystenutic  in¬ 
vestment  in  process^oduct  standardization  as  a  means  to  leverage  expertise  and  increase  productiv¬ 
ity  in  the  delivery  of  tystems  to  customers.  Investments  that  pomise  long-term  leverage  are  generally 
to  be  prefened  over  short-term  pofits. 

2.2.  AppucanoN  Engineering  Perspective 

Application  Engineering  under  leveraged  ^thesis  is  more  similar  to  a  prototyping  pocess  than  to 
a  conventional  software  developnent  pocess,  but  is  oriented  nonetheless  to  podudng  poduction- 
quality  poducts.  Apfdication  eitgineers  ezpess  customer  requirements  in  the  form  of  a  ui^ed  model 
of  a  problem  and  its  solution.  This  model  allows  apfdication  engineers  to  e3q>ress  the  decisions  that 
th^  must  make,  wfaidi  correspond  to  supported  variations  in  tystems  within  the  domain’s  scop.  The 
resultmg  Application  Model  is  a  medium  for  evaluating  the  corresponding  software  poduct  and  for 
medianically  generatii^  associated  work  poducts,  indialing  code  and  documentation,  usii^  reusable 
components.  As  requirements  are  better  understood  or  change,  the  application  engineers  modify  the 
Application  Model,  reevaluate  it,  and  generate  a  revised  poduct 

2J.  Domain  Enginebring  Perspective 

The  goal  of  Domain  Engineering  under  leveraged  ^thesis  is  to  povide  apdication  engineering 
pojectswithacapability  bothtoaeate  an  accurate  nx^el  of  any  poduct  that  is  within  the  designated 
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scope  of  the  domain  and  to  generate  a  valid  software  ^tem  product  consisting  of  all  required  work 
products  corresponding  to  the  model.  Domain  Engineering  accomplishes  this  goal  through  concur¬ 
rent  process  and  product  family  engineering  for  the  domain  in  accordance  with  specified  domain  ob¬ 
jectives.  Additionally,  this  goal  requires  continual  evolution  of  the  domain  as  customer  requirements 
and  tedmol(^  diange.  The  diallenge  is  to  manage  and  accom^dish  this  evolution  in  a  timely  and  sys- 
tematic  fashion.  Although  existing  systems  are  a  valuable  source  of  reusable  components  particularly 


lirtien  a  domain  is  first  being  established  or  caqMiided,  in  leveraged  S^theds,  the  to  evdve  ^ 

dcmudn  rapidly  as  needs  dmnge  is  key  to  the  long-term  success  of  Ae  business. 

2.4.  An  Example  ScENAUO 

As  an  example,  consider  a  hypothetical  process  v4iere  a  business-area  organization  has  established 
a  domain  for  one  of  its  business  lines.  The  organization  initiates  Domain  Engineering  to  formalize  the 
domain  in  light  of  the  organization’s  business  objectives  and  its  past  experience  building  systems  fm’ 
this  business.  The  organization  chooses  the  domain  engineering  staff  to  indude  some  of  the  most  ex¬ 
perienced  managers  and  ei^ineers  in  the  organization  so  that  the  resulting,  concurrently-engineered 
process  and  product  family  standardization  will  refiect  the  best  available  knovdedge  and  esqperti^ 
about  the  problems  to  be  sdved  and  how  valid  solutions  are  created.  Domain  Engineering  rapidly  pro¬ 
ceeds  through  several  iterations  in  which  they  adueve  a  consensus  on  the  scope,  commonalities,  and 
variabilities  of  the  domain,  the  dedsions  that  aj^cation  engineers  must  make  to  build  any  particular 
^tem,  the  requirements,  design,  and  implementation  of  the  suppmted  product  family,  and  the  jH^e- 
ferred  ^{dication  Engineering  process  and  its  automated  support.  The  resulting  Application  Engi¬ 
neering  ^ocess  Support,  including  reusable  assets,  documentation,  and  automation,  is  baselined  for 
subsequent  use  by  client  application  engineering  projects. 

When  a  customer  is  found  who  needs  a  system  that  fits  within  the  scope  of  the  dmnain,  the  organizatimi 
forms  an  application  engineering  project.  The  project  manager  aixl  lead  engineer  have  been  assisting 
in  Domain  Engineering  and  understand  the  needed  system  in  domain-specific  terms.  Domain  Engi¬ 
neering  dedicates  some  of  its  project  support  staff  to  assist  the  {H^oject  in  using  the  domain  most  effec¬ 
tively.  From  customer  information  and  ^scussions.  Application  Engineering  creates  an  Aj^cation 
Model  that  seems  to  correspond  to  what  the  customer  needs.  Application  Engineering  evaluates  the 
model  and  explains  it  to  the  customer.  Based  on  this  interaction,  ^plication  Engineering  discovers 
inaccuracies  and  revises  the  model.  A  software  product  is  then  generated.  Based  on  reviews  and  ex¬ 
ploratory  use  of  the  product.  Application  Engineering  discovers  additional  shortcomings,  leading  to 
further  revision  of  the  model  and  generation  of  a  modified  product 

In  evaluating  the  model  or  generated  product  Application  Engineering  discovers  a  need  that  caimot 
be  properly  modeled.  In  consultation  with  Domain  Engineering,  they  decide  that  the  need  is  in  fact 
wifiiin  the  proper  scope  of  the  domain  and  work  starts  on  evolving  the  domain  accordingly.  In  the 
meantime.  Application  Ertgineering  completes  the  model  and  generates  a  product  that  approximates 
a  solution  to  the  imderstood  need.  Based  on  discussions  with  the  customer.  Application  Engineering 
finds  a  workaround  that  achieves  some  of  the  unmet  need  and  extends  the  model  and  product  accord¬ 
ingly.  When  Domain  Engineering  has  completed  the  agreed-upon  domain  evolution,  ^>plication  En¬ 
gineering  again  revises  the  model,  using  the  added  capability  that  is  now  avaOable,  to  create  an 
enhanced  solution  for  the  customer. 

As  the  organization  initiates  new  application  engineering  projects  or  as  the  needs  of  odsting  client 
projects  change.  Domain  ^gineering  revises  its  consensus  on  the  scope  and  substance  of  the  domain. 
Each  revision  results  in  a  new  baseline  of  Application  Engineering  Process  Support  for  use  by  applica¬ 
tion  engineering  projects.  This  evolution  continues  untQ  the  domain  is  no  Icxiger  a  viable  business  base. 
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DE.  DOMAIN  ENGINEERING  OVERVIEW 


1.  GETTING  STARTED 

Domain  Engineering  is  an  activi^  of  a  Synthesis  process  that  creates  and  supports  a  standardized 
Application  Engineering  process  and  products  in  a  business  area.  Domain  Engineering  is  a  comfMre- 
hensive  iterative  Ufe-<^e  process  with  management,  analysis,  implementation,  and  support  activities 
for  a  fvoduct  family  of  primary  value  to  a  business-area  organization. 

1.1  Objectives 

The  objectives  of  Domain  Engineering  are  to: 

•  Organize  and  direct  resources  to  accomplish  the  business  objectives  of  an  organization 

•  D^e  the  nature,  extent,  and  substance  of  a  i»:oduct  family  that  complements  those  business  ob¬ 
jectives 

•  Provide  leverage  by  which  projects  within  a  domain  can  deliver  a  product  more  effectively, 
predictably,  and  reliably 

1.2  REQinRED  Information 

Domain  Engineering  requires  the  following  information: 

•  Domain  knowledge 

•  Business  objectives 

13  Required  Knowledge  AND  Experience 

Domain  ^igineering  requires  domain  and  software  knowledge  and  operience  in: 

•  The  needs  that  motivate  systems  in  the  domain  (i.e.,  application  migineering  work  ivoducts) 

•  The  environments  in  \riiich  the  systems  in  the  domain  will  operate 

•  How  the  systems  in  the  domain  are  built 

•  How  application  engineering  projects  in  the  domain  are  managed 
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2.  PRODUCT  DESCRIPTION 

Domain  Engineering  creates  four  work  products:  Domain  Plan,  Domain  Definition,  Domain 
Specification,  and  Domain  Implementation.  Domain  engineers  evolve  these  products  in  subsequent 
iterations  of  Domain  Engineering  to  support  future  projects,  consistent  with  organizational  business 
objectives. 

2.1  Domain  Plan 

Purpose  A  Domain  Plan  (see  Section  DE.1)  describes  a  plan  for  domain  evolution  and 

defines  the  tasks  and  resource  allocations  for  domain  development 
increments. 

lir^ication  The  expected  needs  of  the  projected  product  market  in  the  business  area  are 

Criteria  sufficient  to  compensate  for  projected  costs  and  risks  of  domain  development. 

2.2  Domain  Definition 

Purpose  A  Domain  Definition  (see  Section  DE.2.1)  defines  the  informal  scope  and 

orientation  that  characterize  a  viable  domain. 

f^tification  The  Domain  Definition  captures  sufficient  information  to  allow  domain 

CrUeria  engineers  to  describe  any  existing  or  potential  system  in  the  domain. 

2.3  Domain  SPEcmcATioN 

Purpose  A  Domain  Specification  (see  Section  DE.2.2)  formalizes  expert  knowledge  of 

how  to  express  problems  in  the  domain  and  how  to  create  corresponding 
solutions  for  the  problems. 

Vetification  The  Domain  Specification  precisely  expresses  the  domain  as  captured  in  the 

Criteria  Domain  Definition. 

2.4  Domain  Implementation 

Purpose  A  Domain  Implementation  (see  Section  DE.3)  is  an  implementation  (with 

documentation  and  automated  support)  of  the  Application  Engineering 
process  and  product  family  for  the  domain,  as  prescribed  by  the  Domain 
Specification. 

Veiykation  The  Domain  Implementation  provides  the  standardized  Application 

Criteria  Engineering  process  and  product  family  desaibed  in  the  Domain 

Specification. 

3.  PROCESS  DESCRIPTION 

Domain  Engineering  is  an  interaction  among  the  four  steps  shown  in  Figure  DE~1. 
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to  Application  Et^ineering 

RgureDE-1.  Dtmain  Engineering 


3.1  Procedure 

Fbllow  these  steps  for  the  Domain  Engineering  Activity. 

Step:  Domain  Management  Activity 

Action  Plan,  monitor,  and  control  the  use  of  domain  resources  to  provide 

standardized  process  and  product  family  for  a  domain  of  interest  to  achieve 
organizational  business  objectives. 

Result  Domain  Plan 

Haaistics  Define  long-range  and  near-term  objectives  for  a  business  area.  Organize  and 

manage  domain  resources  to  achieve  those  objectives. 
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Step:  Domain  Analysis  Activity 


AcdoH 

JuptH 

Ruub 

Beuristks 


Scope  and  specify  a  d(Mnain  based  on  an  anafysis  of  business  objectives  of  an 

organization. 

Domain  Plan 

•  Domain  Definition 

•  Domain  Spedfication 

•  Create  an  informal  definition  of  the  domain.  Qiaracterize  its  scope,  the 
aspects  common  to  all  ^ems  in  the  donuun,  and  the  features  that  vary 
aaoss  systems  in  the  domain.  Ez{didtly  state  what  is  not  part  of  the  do¬ 
main.  l^ovide  a  glossary  of  common  terms.  Assess  the  viabilify  of 
supporting  each  of  the  aspects  you  have  characterized. 

•  Predsely  specify  problems  within  the  scope  of  the  domain.  Desoibe  both 
common  problems  and  variations  in  those  problems.  Spedfy  solutions  to 
the  problems  in  the  domain  so  that  the  solutions  vary  in  the  same  way  as 
the  problems.  Spedfy  the  standardized  Application  Engineering  process 
for  building  applications  in  the  domain. 


St^  Domain  Impkaientation  Activity 


Action 

Input 


Besidt 

Heuristics 


Implement  the  domain  as  defined  by  the  Domain  Spedfication. 

•  Domain  Definition 

•  Domain  Specification 

•  Domain  Plan 

Domain  Implementation 

•  Implement  the  ja-oduct  fiunify  and  i^ocess  described  in  the  Domain 
Spedfication.  Incorporate  variations  into  the  implementation  of  the 
solutions. 

•  Create  the  standards  and  procedures,  in  documentation  and  supporting 
automation,  that  institute  a  standardized  Application  Engineering  process 
as  spedfied  in  the  Domain  Spedfication. 


Step:  Project  Support  Activity 


Action  Support  a  project  in  performing  the  Apfdication  Engineering  process. 

It^na  Domain  Implementation 

Heuristics  Deliver,  install,  and  support  the  Domain  Implementation  for  use  by  projects 

in  the  domain. 
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Risk  Management 

Fisk  The  products  of  Domain  Engineering  (standardization  of  Ap{^catkm 

Engineering  jvoducts  and  |a-ocess)  will  not  lead  to  standardized  dmnain 
I^actices  on  projects. 

Im^kation  The  Domain  Engineering  investment  will  not  produce  projected  benefits  for 

the  business  organization. 

Mit^athn  •  Staff  the  Domain  En^neering  work  with  aperienced  project  managers 

and  engineers.  Ensure  that  all  work  is  actively  reviewed  by  other  ei^ri- 
enced  managers  and  engineers  and  is  adequately  reviewed  by  all  partici¬ 
pants  of  application  engineering  projects. 

•  Evaluate  the  effectiveness  of  the  Domain  Engineering  process  and  work 
products  relative  to  past  project  esperiences.  Ensure  that  the  diaracteris- 
tics  of  that  experience  or  the  resulting  ^tems  are  not  in  conflict  with  the 
process  and  work  products. 

•  Provide  unified  management  of  domain  engineering  and  api^cation 
engineeriiig  projects.  Establish  an  organizational  commitment  to  the 
combined  success  of  all  participants. 

4.  INTERACTIONS  WITH  OTHER  ACnVITIES 

4.1  Feedback  TO  Information  Sources 

None 

4.2  Feedback  From  Product  Consumers 

Contingauy  The  standardized  product  family  is  inadequate  to  support  the  needs  of 

particular  customers. 

Source  Application  Engineering 

Besponse  •  Determine  that  expressed  needs  are  outside  of  or  otherwise  conflict  with 

chosen  domain  objectives  or  cannot  be  viably  satisfied  given  available 
domain  resources. 

•  Evolve  the  domain  to  accommodate  changing  needs. 

ConFngmty  The  standardized  ^)plication  Engineering  process  is  ineffident  or  leads  to 

less-than-ideal  results  for  a  particular  project. 

Source  Application  Engineering 

Reqionse  •  Determine  that  the  benefits  of  process  standardization  outweigh  the 

interests  of  the  particular  project 
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•  Evolvethedefimti(»oftheAi^catkxiEii^etfii^processtor^ectttiis 
project's  esperience  or  to  be  adaptaUe  to  the  particular  conditioas 
concern. 


Levels 


DE.1.  DOMAIN  MANAGEMENT  ACnvITY 


1.  GETTING  ST4RTED 

Domain  Management  is  an  activi^  of  PcMnain  Engineering  for  managing  buriness-area  resources  to 
achieve  assigned  business  objectives.  The  business*area  or^mization  |vovides  resources  and  direction 
for  both  domain  engineering  and  associated  api^cadon  engineering  projects. 

Domain  Engineering  develops  and  evolves  a  domain  through  a  series  of  increments.  The  Domain  Plan 
lays  out  both  a  master  plan  for  evolution  throu^  {projected  increments  (evolution  plan)  and,  as  each 
increment  is  initiated,  a  detailed  (dan  for  each  increment  (increment  plan).  The  evolution  {dan  deter¬ 
mines  the  nature  of  the  market  addressed  and  how  resources  are  allocated  between  domain  engineer¬ 
ing  and  application  engineering  (Mrojects.  An  inorement  jdan  determines  how  domain  engineering  re¬ 
sources  are  applied  to  aeate  an  efGdent  Application  l^gineering  process  and  a  high*<iuality  product 
family. 

Domain  Management  monitors  domain  engineering  performance  to  assess  jn-ogress,  ensure  proper 
adherence  to  plans,  and  guide  needed  revisions  to  the  evolution  and  increment  plans.  A  concern 
of  Domain  Management  is  coordinating  Domain  Engineering  t^vities  to  support  the  needs  and  prio¬ 
rities  of  targeted  application  engineering  (vojects  in  satisfying  customers’  ne^  and  in  achieving  the 
overall  objectives  of  the  business  area.  Domain  Management  assists  the  management  of  targeted 
application  engineering  projects  to  aeate  plans  that  ensure  optimal  leverage  from  the  domain  and 
to  identify  enhancements  needed  by  the  projeds  for  indusion  in  timely  inaements  of  domain 
evolution. 

1.1  Objectives 

The  objective  of  Domain  Management  is  to  manage  business-area  resources  to  adiieve  the 
organization’s  business  objectives.  Management  establishes  domain  objectives  for  the  organization 
to  guide  the  aeation  and  revision  of  an  increment  {dan  for  incremental  domain  development  aiul 
evolution.  Domain  evolution  is  concerned  with  the  overall  trends  in  the  market  for  the  buriness  area 
and  how  resources  should  be  applied  to  best  serve  the  evolving  market.  The  primary  concern  in  in¬ 
ning  for  domain  ^'volution  is  {vojecting  the  evolutitm  of  market  need  and  organizational  capabilifyto 
meet  that  need  over  time. 

Ead)  inorement  of  domain  developnent  should  result  in  the  ability  to  serve  a  particular  level  of 
market  need.  Fbr  eadi  increment  of  development.  Domain  Management  develops  a  {dan  to  deliver 
capabilities  that  matdi  the  needs  of  targeted  application  ei^eeriQg  projects.  Af^cation  eng^ecr- 
ing  projects  are  jdanned  in  coordination  with  Domain  Management  and  with  an  awareness  of  domain 
objectives  and  capabilities,  to  meet  particular  customer  needs. 
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1.2  Required  Information 

The  Domain  Management  Activity  requires  the  fdlowing  information: 

•  Business  objectives,  spedficalfy  the  priorities  of  executive  management  for  business  area 
development 

•  Domain  Definition:  Domain  Status 

13  Required  Knowledge  AND  Experience 

The  Domain  Management  Activity  requires  domain  and  business-area  knowledge  and  e]q)eri«ioe  in: 

•  The  characteristics  of  the  market  for  the  business  area 

•  All  aspects  of  strategic  business  devdopment  and  business-area  management  in  the 
organization,  induding  how  to  create  a  long-range  business  plan 

•  All  aspects  of  application  project  management  in  the  organization 

2.  PRODUCT  DESCRIPTION 

Ntane  Domain  Plan 

Purple  Define  long-range  and  near-term  objectives  and  organize  and  manage  dcnnain 

resources  to  adiieve  those  objectives. 

Coment  A  Domain  Plan  consists  of  three  parts: 

•  Domain  Evolution  Plan.  The  Domain  Evolution  Plan  defines 
long-range  objectives  for  the  domain  and  organizes  resources  to 
achieve  them.  This  plan  is  strategic  in  nature  and  recognizes  that  both 
an  organization's  capabilities  and  its  opportunities  for  profitable 
business  chaqge  over  time.  Not  all  objectives  can  be  met  initially  but 
must  develop  in  the  course  of  time,  in  increments  that  balance 
alternative  uses  of  available  resources  against  the  potential  for  return. 

•  Praetica  and  Proeeibtres.  Practices  and  Procedures  preso’ibe  the 
preferred  practices  and  procedures  that  are  to  guide  the  (xroper 
performance  of  domain  develoi»nent 

•  Domain  IneremaU  Plans.  A  Domain  Increment  Plan  spedfies  how  to 
organize  and  mwage  Domain  Engineering  resources  to  achieve 
near-term  domain  objectives. 

Both  the  Domain  Evolution  Plan  and  the  Domain  Increment  Plans  indude  the 
following: 

•  Jttdbi^iialldfcldaitificationctf  uncertainties  in  meeting  alkxatedbudness 
(for  the  Domain  Evolution  Plan)  or  domain  (fir  a  Domain  Incrmnent 
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Plan)  objectives,  assessment  of  the  risks  of  fiulure,  and  identificitioo  of 
mitigation  strat^es. 

•  Ot^ecHm.  The  scope  and  focus  of  support  to  be  provided  for  tiie 

domain  or  the  inaement  ctf  domain  development,  reflecting  the  needs 
and  priorities  of  targeted  application  engineering  projects.  Scope  is  in¬ 
dicated  by  an  identification  of  previously  built  systems  upon  the 

domain  will  be  based;  focus  is  indicated  by  the  mix  of  near-term  and 
long-term  business  objectives.  Objectives  are  divided  into  risk  objec¬ 
tives  and  product  objectives.  Risk  objectives  attempt  to  mitigate  risks 
identified  in  the  risk  analysis.  Product  objectives  establish  goals  and 
success  aiteria  for  aeating  specific  work  products. 

•  Schedule.  The  allocation  oi  domain  resources  to  develc^ent  iiKaremmits 
that  satisfy  domain  objectives  or  to  activities  within  an  increment  that  sat¬ 
isfy  inaement  objectives.  The  schedule  establishes  specific  milestones 
and  success  criteria  for  domain  development  increments  or  for  the 
activities  of  a  development  increment. 

•  Issues.  A  description  of  issues  that  arise  in  performing  the  plan. 

To  the  extent  possible,  the  form  of  a  Domain  Evolution  Plan  should  be  the 
form  your  organization  currently  uses:  the  Domain  Evolution  Plan  should 
follow  the  form  used  for  long-range  business  {banning;  Practices  and 
Procedures  should  follow  the  form  used  for  standardizing  the  practices  of 
application  projects;  and  the  Domain  Increment  Plans  should  follow  the  form 
used  for  application  project  planning. 

The  verification  criteria  for  the  Domain  Evolution  Plan  are: 

•  The  plan  must  show  how  near-term  objectives  contribute  to  long-range 
objectives.  All  near-term  objectives  must  support  long-range  objectives. 

•  The  projected  market  for  products  in  the  business  area  must  be  large 
enough  to  compensate  sufficiently  for  projected  costs  and  risks. 

•  For  the  Domain  Evolution  Plan: 

-  The  plan  is  complete  (i.e.,  it  addresses  all  business  objectives). 

-  The  plan  is  credible  (i.e.,  it  sets  forth  a  strategy  that  is  feasible, 
given  projected  resources). 

-  Domain  objectives  are  realistic,  given  the  projected  availability  of 
resources  and  strength  of  the  competition. 

-  All  important  risks  are  identified  and  addressed. 

-  Criteria  are  defined  to  measure  progress  against  objectives  and  to 
choose  among  alternative  plans  or  indicate  a  need  for  replanning. 
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•  EacbDomaiii  Increment  Plan  institutes  a  plan  that  seems  likdy  to  aeUeve 
the  objectives  assigned  to  that  D(»iain  Engiim^ing  increment  by  the 
Dtunain  Evctiution  Plan. 

3.  PROCESS  DESCRIPTION 

The  Domain  Management  Activity  consists  of  three  steps  as  shown  in  Figure  DE.1-1. 


to 

DonudnAnafyil^  Domain  ImpUmenlatUm,  and  PtojoctStqiport 


Injure  DE.1'1.  Domain  Management  ftoooi 

The  Domain  Evolution  step  begins  upon  creation  of  a  donudn  and  continues  until  the  domain  is  no 
longer  judged  to  be  econtunically  viable.  The  Domain  Evolutitm  Plan  prescribes  a  series  of  Domain 
Development  increments.  Eadi  increment  is  fdanned  and  performed  iterativdy  until  its  (^jectives  in 
the  Domain  Evolution  Plan  are  met  The  Domain  Evtdution  Plan  is  subject  to  revision  after  the 
ocm^etion  of  each  inaement  to  reflect  {»x)gress  or  dumging  needs  of  the  market  or  targeted  applica¬ 
tion  engineerii^  projects  and  their  customers.  The  step  to  Institute  1  <actices  and  Procedures  occurs 
beftnre  the  initiation  of  the  first  inaonent  of  Domain  Development  and  is  revisited  as  needed  to 
date  the  Practices  and  Procedures  to  ensure  an  effective  and  effictoitiqpproacfa  to  Domain  EngjneCTing. 

3.1  PmXXDURE 

Follow  these  steps  for  the  Dcmiain  Management  Activity. 

Stqps  Dmnain  Evolution 

Action  Create  a  plan  for  Domain  Evdution. 

Input  •  Business  objectives 
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•  Dcmiain  Definitioo:  Domain  Status 

Domiun  Plan:  Dcmam  Evdution  Ran 

•  Develop  a  set  domain  objectives  that  will  guide  you  in  the  lof^-tenn 
evolution  of  the  domain.  Develop  a  prdiminary  statement  ctf  domain  ob¬ 
jectives  that  expresses  the  strategic  mission  of  the  organization.  (Refer  to 
the  heuristics  fcv  the  Domain  Devel<^)ment  step  fcv  suggestions  <»  a  risk- 
based  management  process  that  you  can  also  apply  in  perfuming  this 
step.) 

•  Develop  market  projections  as  a  basis  for  understanding  current  and 
future  custcMner  needs  to  be  met.  Refine  the  objectives  to  match  percdved 
market  opportunities.  Consider  the  following  questions: 

-  What  are  the  oitical  aspects  of  your  market? 

-  Who  are  your  customers  and  vdiat  factors  are  most  important  to 
them  in  deciding  to  award  contracts? 

-  What  type  of  products  will  you  produce  to  address  this  market? 

-  Who  are  your  competitors?  What  are  their  strengths  and 
weaknesses? 

-  What  are  your  strengths  and  weaknesses? 

-  How  many  systems  do  you  expect  to  produce  both  in  the  first  year 
and  as  the  domain  matures? 

•  Describe  a  strategy  for  achieving  domain  objectives.  The  life  (^de  of  a 
domain  comprises  four  phases: 

-  Coneqftion.  A  small,  cohesive  group  explores  the  boundaries  of  a 
domain  to  estaUish  a  viable  market  basis;  project  suppcxt  is  not 
viable  yet 

-  Elaboration.  One  or  a  few  very  similar  projects  are  directly 
supported;  domain  evolution  emfdiasizes  needs  that  are  impcxtant 
to  most  customers. 

-  Expansion.  Supporting  the  planned  diversity  of  projects  is  now 
viable;  market  oj^rtunities  drive  further  domain  evolution. 

-  Consolidation.  Little  additional  diversification  is  viable;  projects 
are  mans^ed  to  fit  within  the  supported/variations  in  domain 
capabilities  as  much  as  possible. 

•  Develop  a  profile  of  the  market  to  be  supported  as  the  domain  matures. 
Provide  details  in  terms  of  evolving  domain  objectives. 
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•  Develop  a  profile  of  the  evolution  (tf  automation  to  be  devel(^)ed  in 
suj^rt  of  api^cation  engineering  projects.  Consider  the  degree  of  auto¬ 
mation  you  expect  to  de[doy  in  suppwt  oi  triplication  ei^ineeriqg,  bodi 
initially  ^  as  the  domain  matures. 

•  Develop  a  profile  of  the  resources  needed  to  fulfill  domain  objecthws. 
Consider  both  quantitative  and  qualitative  needs  in  ail  skill  categories. 
Project  how  these  resources  are  to  be  allocated  between  domain  engineer¬ 
ing  and  air>lication  engineering  projects.  Consider  how  resources  will  be 
allocated  between  dmnain  development  and  afr^ication  engineering 
projects. 

•  Define  a  series  of  domain  development  increments,  and  define  objectives, 
consistent  with  domain  objectives  and  allocate  them  to  increments. 
Consider  the  following  questions: 

-  How  do  you  oqiect  the  market,  your  business,  and  your 
competition  to  change  over  time? 

-  What  are  the  long-term  risks  in  developing  the  domain,  and  how 
will  you  mitigate  each  one? 

-  What  are  the  objectives  for  the  domain,  and  what  are  the  objectives 
of  each  increment  of  development  that  is  to  achieve  those 
objectives? 

Step:  Institute  Practices  and  Procedures 

Develop  and  document  standard  practices  and  procedures  to  be  followed  in 
the  activities  of  Domain  Engineering. 

None 

Domain  Plan:  Practices  and  Procedures 

•  Prescribed  practices  and  procedures  should  encompass  administrative, 
software  development  (e.g.,  requirements  and  design  methods,  coding  and 
documentation  standards),  project  management  and  control,  and  quality 
assurance  (e.g.,  testing,  walkthrough,  and  review  procedures). 

•  Configuration  management  procedures  are  a  k^  element  for  controlling 
iterative  domain  development.  Each  iteration  of  domain  develofmient  is 
represented  Ity  one  version  of  each  domain  engineering  work  juroduct  that 
you  produce.  Feedbadt  on  the  use  of  a  product  version  leads  to  the 
creation  of  a  new  version  in  a  later  iteration  of  develo[»nent 

•  Consider  how  consistent  and  quality  standards  will  be  achieved  in 
donuun  practices. 

Step:  Domain  Development 

Actum  Create  a  plan  for  developing  a  domain  increment 


Action 

Input 

Resutt 

Heuristics 
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•  Practices  and  Procedures 

•  Domain  Definition:  Domain  Status 

Domain  Increment  Plan 

•  A  Domain  Develc^ent  increment  consists  of  repeated  (^es  through  a 
ivocess  oomfdsed  four  steps  as  shown  in  Figure  DE.1-2.  This  guidance 
assumesyou  are  e3q)erienced  in  project  nuuugement.  Refer  to  the  descrip¬ 
tions  of  Ae  fvocess  model  and  activities  for  the  ESP  (Software  Productiv¬ 
ity  Consortium  1992b)  for  a  detailed  project  nuuiagement  method  that  you 
can  follow  to  tailor  and  elaborate  this  process. 


•  The  Domain  Evolution  Plan  identifies  the  objectives  to  be  met  by  the 
inaement  Identify  and  rank  the  domain  deveIoi»nent  risks  faced  tty  the 
organization  in  meeting  these  objectives. 

-  Arecurringclassofrisksthatdomaindevelopmentmustfaceisthe 
near-term  ability  of  targeted  api^cation  engine^ing  injects  to 
create  required  products.  Another  recurring  dass  of  risks  involves 
how  to  evolve  the  domain  to  meet  long-range  domain  objectives. 
Actions  to  mitigate  these  risk  dasses  may  conflict 


Lev-19 


DE.1.  Domain  Management  Activity 


-  Another  important  class  of  risks  relates  to  problems  discovered  in 
previous  itet  .dons  of  the  Domain  Engineering  j^-ocess. 

•  Develop  a  prioritized  set  of  near-term  increment  (^jectives  that  address 
the  risks  identified  in  the  risk  analysis.  These  objectives  may  be  revised,  as 
Domain  Engineering  iterates,  to  meet  the  Domain  Evolution  Plan 
objectives  for  the  increment. 

-  Adomain-development  approach  must  balance  long-term  domain 
objectives  against  the  short-term  needs  of  targeted  projects. 

-  Each  objective  should  have  associated  success  criteria  that  are 
used  to  determine  whether  the  objective  has  been  met.  The  success 
criteria  should  be  written  in  such  a  way  that  th^  are  directly 
measurable  (if  possible). 

-  Objectives  are  often  stated  in  terms  of  variations  that  dbaracterize 
systems  in  the  domain  or  variations  to  be  allowed  in  the  practice 
of  Application  Engineering. 

•  Develop  a  schedule  that  allocates  resources  to  tasks. 

-  Create  specific  goals  and  completion  criteria  for  each  task.  Eadi 
task  is  diaracterized  a  Domain  Engineering  activity  to  be  per¬ 
formed  and  completion  criteria  appropriate  to  that  activity.  The 
full  set  of  tasks  must  address  the  near-term  objeaives  within  the 
resource  budget  provided.  If  the  resource  budget  does  not  allow  all 
the  objectives  to  be  addressed,  the  objectives  with  the  highest 
priority  should  be  addressed. 

-  Plan  for  short  iterations  so  that  mistakes  made  in  fi-ont-end  tasks 
may  be  caught  and  corrected  quickly  in  a  subsequent  iteration.  It¬ 
erations  at  the  beginning  of  the  life  c^e  of  a  domain  should  be  par- 
ticularfy  short  (three  to  four  months)  to  compensate  for  the  likefy 
learning  curve  in  domain  concepts. 

•  Monitor  domain  engineering  work  progress  to  planned  milestones  and 
completion  criteria. 

-  The  schedule  establishes  milestones  and  completion  criteria  for 
activities  that  are  used  to  evaluate  progress.  Whenever  new  issues 
are  identified  or  progress  differs  from  that  planned,  evaluate 
whether  to  document  your  concerns  for  future  planning  or  to 
revise  the  current  plan  for  immediate  action. 

-  Document  the  source,  implications,  and  possible  and  actual 
resolutions  of  each  issue. 


3.2  Risk  Management 

Ksk  Domain  plans  will  not  be  met  within  schedule  with  allocated  resources. 
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Domain  capabilities  will  £all  sbcart  of  {dans. 

•  Review  plans  with  e^)erienced  engineers  to  ensure  that  planned 
development  is  technics^  viable. 

•  Reevaluate  domain  objectives  and  re^dan  domain  evolution  to  provide  for 
shorter  iterations  that  achieve  essential  capabilities  sooner;  defer  work  on 
less  important  objectives. 

Market  needs  will  not  be  met  by  projected  development. 

Demand  for  projects  will  not  be  sufficient  to  justify  |danned  investment  in  the 
domain. 

Review  objectives  and  plans  with  marketing  and  major  customers  to  ensure 
that  market  needs  are  properly  represented. 

Domain  engineers  resist  using  standardized  practices  and  procedures. 

Inefficient  operation  and  employee  dissatisfaction  will  reduce  productivity. 

•  Involve  domain  engineers  in  developing  practices  and  procedures. 

•  Provide  education  and  apprenticeships. 

•  Conduct  pilot  projects  that  emphasize  learning  new  skills  over  product 
delivery. 

Domain  engineers  fail  to  recognize  when  to  terminate  an  iteration. 

•  There  will  be  excessive  detail  in  products  without  adequate  foundation  or 
potential  benefit 

•  Schedules  will  slip. 

Review  objectives  and  completion  oiteria  to  make  sure  they  are  specific  and 
understood  by  the  domain  engineers. 

Project  needs  will  not  be  met  planned  development 

Provided  reusable  assets  will  not  have  sufficient  value  to  targeted  projects  to 
justify  costs  of  the  domain. 

Review  objectives  and  plans  with  project  managers  to  ensure  that  the  needs  of 
their  projects  and  the  projects'  customers  are  properly  understood. 

Domain  plans  will  not  be  met  within  schedule  with  allocated  resources. 

Domain  capabilities  will  fall  short  of  plans. 

•  Review  plans  with  experienced  engineers  to  ensure  that  planned 
development  is  tediniciffiy  viable. 
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•  Reevaluate  objectives  and  jM'oject  needs  to  focus  suj^rt  on  key  needs  at 
the  targeted  projects  first;  defer  work  on  less  urgent  objectives. 

•  Revise  the  Domain  Inaement  Han  to  add  or  defer  activities,  or  to 
reallocate  time  and  resources  among  {banned  activities,  as  jxiorities 
dictate. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  iNfDRMATioN  Sources 

The  Domain  Definition  and/or  Domain  Specification  fails  to  provide  the 
needed  capabilities  required  by  the  Domain  Plan. 

Domain  Analysis  Activity 

Describe  ways  in  which  the  Domain  Definition  and/or  Domain  Specification 
fail  to  provide  the  necessary  capabilities.  Modify  schedule  to  allow  completion 
of  indicated  Domain  Definition  or  Domain  Spedfication  revisions. 


Contingmty 
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4.2  FteDBACK  From  Product  Consumers 
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Customer  needs  are  not  being  met  by  the  domain. 

Project  Support  Activity 

•  Revise  the  Domain  Plan  to  accommodate  new  needs. 

•  Determine  that  needs  are  incompatible  with  your  organization’s  business 
objectives. 

Project  needs  are  not  being  met  by  the  domain. 

Project  Support  Activity 

•  Revise  the  Domain  Plan  to  accommodate  new  needs. 

•  Determine  that  the  needs  of  a  project  are  incompatible  with  the 
organization’s  business  objectives  and  therefore  outside  the  proper 
boundaries  of  the  domain. 

Practices  and  procedures  are  either  ineffective  or  ineffident 

•  Domain  Analysis  Activity 

•  Domain  Implementation  Activity 

•  Project  Support  Activity 

Revise  practices  and  procedures  to  reflect  domain  experience. 
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The  Domain  Plan  is  too  ambitious  for  available  resources  or  aq>^tise. 

•  Domain  Analysis  Activity 

•  Domain  Implementation  Activity 

•  Allocate  additional  resources  or  time  to  domain  development. 

•  Refine  the  Domain  Plan  to  reduce  the  scope. 
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This  page  intentionalfy  Ufi  blank. 
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1.  GETTING  STARTED 

Domain  Analysis  is  an  activity  of  Domain  Engineering  for  stutfying  and  formaliang  a  business  area 
as  a  domain.  The  purtx>se  of  formalizing  a  domain  is  to  standardize  and  leverage  knovdedge  of  how 
recurring  and  varying  customer  requirements  affect  the  form  and  content  of  a  product  The  scope  of 
adomain  is  a  business  decision  bas^on  evaluations  of  available  opertise  and  potential  business  op¬ 
portunities.  Domain  Analysis  specifies  a  standardized  Application  Engineering  process  and  product 
f^amily  and  verifies  that  a  corresponding  Domain  Implementation  meets  that  specification. 

1.1  Objectives 

The  objectives  of  Domain  Analysis  are  to: 

•  Determine  scope  and  to  evaluate  the  economic  viability  of  a  domain 

•  Establish,  manage,  and  evolve  a  repository  of  domain  knowledge 

•  Specify  an  Application  Engineering  process  and  product  family  appropriate  to  the  domain 

1.2  Required  Information 

Domain  Analysis  requires  the  following  information: 

•  Business  area  knowledge 

•  Domain  Plan:  Domain  Objectives 

•  Domain  Implementation 

IJ  Required  Knowledge  AND  Experience 

Domain  Analysis  requires  domain  and  software  knowledge  and  experience  in: 

•  The  needs  that  motivate  ^tems  in  the  domain 

•  The  environments  in  whidi  these  systems  operate 


How  these  systems  are  built 
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2.  PRODUCT  DESCRIPTION 

Domain  Analysis  aeates  two  work  products:  Domain  Definition  and  Domain  Specification. 

2.1  Domain  Definition 

Purpose  A  Domain  Definition  (see  Section  DE.2.1)  is  an  infcmnal  description  of  the 

^tems  in  a  business  area  that  form  a  domain.  A  Domain  DdSnition 
characterizes  how  existing  systems,  ^tems  being  developed  in  ongmsg 
projects  in  the  domain,  and  potential  future  ^tems  are  similar  and  how  th^ 
differ. 

Verification  The  Domain  Definition  captures  sufficient  information  to  allow  domain 

Criter  '■  engineers  to  describe  accurately  any  odsting  or  potential  system. 

2.2  Domain  SPEcmcATiON 

Purpose  A  Domain  Specification  (see  Section  DE.2.2)  precisely  characterizes  a 

product  family  for  the  domain  and  an  Application  Engineering  process  for 
constructing  members  of  that  family. 

Verification  The  Domain  Specification  precisely  aq>resses  the  domain  as  captured  in  the 

Criteria  Domain  Definition. 

3.  PROCESS  DESCRIPTION 

The  Domain  Analysis  Activity  consists  of  the  three  steps  shown  in  Figure  DE.2-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Analysis  Activi^. 

Step:  Domain  Definition  Activity 

Action  Characterize  the  domain  to  satisfy  domain  objectives  (see  Section  DE.2.1). 

Input  Domain  Plan 

Raadt  Domain  Definition 

Heuristics  •  Characterize  the  domain  1^  defining  its  scope  (i.e.,  classes  of  ^tems, 

characteristics,  or  functions  induded  and  exduded  from  the  domain)  and 
how  induded  systems  are  distiiiguidied  from  one  anotho:.  These  definitions 
are  a  basis  for  judging  the  qualitative  and  econcnnicdiaracteristics  the  do¬ 
main  to  determine  Aether  the  domain  as  d^ed  wfll  be  eooixnnicalfy 
viable. 

•  Consider  how  a  product  for  a  ^tem  is  similar  and  distinguishable  from 
a  product  for  existing  systems. 
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Figure  DE^l.  Dooiam  Analysis  Rrooea 

•  Use  this  definition  as  a  basis  for  judging  the  qualitative  and  economic 
characteristics  of  the  domain  to  determine  whether  the  domain,  as 
defined,  will  be  economically  viable.  If  analysis  of  the  Domain  Definition 
fails  a  test  of  economic  viability,  reevaluate  the  scope  of  the  domain  in 
terms  of  domain  dijectives. 

Step:  Domain  Spedfication  Activity 

Ac^n  Specify  Application  Engineering  Process  Support  (see  Section  DE.2.2). 

/iijpitf  Domain  Definition 

Jtesufr  Domain  Specification 

Heuristics  •  Create  a  standard  ^;^ication  l^igineering  farocess  for  the  domain. 

Ensure  that  all  needs  of  (aojects  are  flexibly  suf^rted. 

•  Design  an  Application  Modeling  Notation  for  commimication  of  tystem 
requirements  and  constraints  among  customers  and  apfdication  engi¬ 
neers.  Identify  the  decisions  that  an  application  ei^eer  must  make  to  de¬ 
scribe  fully  the  variations  in  a  tystem.  'Dus  notation  must  accommodate  as¬ 
pects  appropriate  for  the  product  family  (sudi  as  functional  [e.g., 
behavioral]  and  nonfu  icdonal  aspects  [e.g.,  size,  timing,  fault  mlerance, 
hardware  architecture,  hardwar^software  configuration])  so  that  the 
application  engineer  can  adequatefy  eaqvess  customer  requirements.  This 
notation  diould  be  based  on  existing  (formal  or  informal)  notations  used 
by  domain  experts. 


DE2.  Domain  An«Iy«is  Activity 


•  Ensure  that  the  Application  Modeling  Notation  is  precise  enough  to  be 
used  as  a  source  for  mapping  into  exact  ^tem  solutions.  Create  staiKlard- 
ized  requirements  for  the  domain.  This  description  must  establish  both  the 
common  and  variable  aspects  of  the  behavior  and  constraints  of  fu’oduct 
family  members.  An  unambiguous  specification  of  requirements  is  needed 
so  that  ckxnain  imjiemenmrs  can  determine  ^lat  impact  a  derkfnn  has  on  a 
system.  This  also  provides  a  basis  for  eaqilaining  die  notatkxi  to  appijratjnn 
engineers. 

•  Create  a  standardi^d  design  for  the  product  family.  The  design  must 
satisfy  both  the  common  and  variable  aspects  of  the  product  family.  A  stan¬ 
dardized  design  indudes  both  design  structures  that  define  various  views 
of  the  product  structure  and  components  from  which  a  product  is 
constructed  to  satisfy  customer  requirements. 

Step:  Domain  Verification  Activity 

Verify  the  correctness,  consistent^,  and  completeness  of  domain  engineering 
work  products  (see  Section  DE.2.3  for  motivation). 

•  Domain  Definition 

•  Domain  Spedfication 

•  Domain  Implementation 
None 

•  Verify  the  consistency  and  completeness  of  the  Domain  Definition. 

•  Verify  that  the  representation  of  the  Application  Engineering  process  in 
the  Domain  Spedfication  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Definition. 

•  Verify  that  the  representation  of  the  application  engineering  product  in 
the  Domain  Spedfication  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Definition. 

•  Verify  that  the  Product  Implementation  is  consistent  and  complete  with 
respect  to  the  Domain  Spedfication. 

•  Verify  that  the  representation  of  the  Application  Engineering  process  in 
the  Process  Support  is  consistent  and  complete  with  respect  to  its 
representation  in  the  Domain  Spedfication. 

3.2  Risk  Management 

Ris*  The  cost  of  an  increment  of  Domain  Analysis  is  projected  to  otceed  the  budget. 

Implication  Insufficient  resources  exist  to  complete  a  planned  iteration  of  Domain 

Engineering. 


Action 

Input 

Result 

Heuristics 
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Reduce  the  curr^t  scope. 


MUfathm  • 

•  Seek  a  diaoge  in  ckunain  objectives  tx*  an  inaease  in  the  budget  for  the 
inaement  fr<»n  Donudn  Management 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  F^back  TO  Information  Sources 

Contingmcy  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Respond  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  mamfa  available 

capabilities.  Complete  a  Domain  Definition  and  a  Domain  Specification  that 
satisfy  the  Domain  Plan  as  dosely  as  possible. 

Coatingmey  The  Domain  Implementation  does  not  satisfy  the  Domain  Specification. 

Source  Domain  Implementation  Activity 

Response  Qarify  the  intent  of  the  Domain  Spedfication. 

ContU^ency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  ineffident. 

Source  Domain  Management  Activify 

Response  Describe  the  ways  inuhich  the  {xactices  and  procedures  are  either  ineffective 

or  inefiGdent.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

ConRngeney  Suggestions  are  made  for  Domain  Specification  dianges  to  eqdoit  unforeseen 

opportunities.  Fbr  example,  a  situation  vdiere  substantial  software  is  made 
available  for  use  in  the  Efomain  Imj^emmitation  that  was  not  available  when 
the  Domain  Specification  was  oomi^eted. 

Source  Domain  Imi^ementation  Activify 

Response  •  Revise  the  Domain  Specification. 

•  Refer  to  Domain  Management  for  future  i^annii^. 

•  Reject  the  changes  due  to  conflicts  with  the  IXnnain  Definition. 

Contingmcy  The  Domain  Definition  and/or  Donudn  Specification  fails  to  provide  the 

capabilities  required  by  the  Domain  Plan. 


Source 


Domain  Management  Activity 


Response  Evolve  the  Domain  Definition  and  die  Domain  Specification  to  be  consi^itt 

with  the  Dmnain  Plan. 

Contii^eney  The  Domain  Specification  is  incomidete,  ambiguous,  or  inconsistent 

Source  Domain  Implementation  Activity 

Response  Revise  the  Domain  Specification  to  correct  the  inadequacies. 

ContU^mcy  The  standardized  Apfdicadmi  Engineering  process  is  inefficient  or  leads  to 

less-than-ideal  results  for  a  particular  project 

Source  Project  Support  Activity 

Response  •  Determine  that  the  benefits  of  process  standardization  outwei^  the 

interests  of  the  particular  {x-oject. 

•  Evolve  the  definition  of  the  Application  Engineering  process  to  reflect  the 
project’s  experience  or  to  be  adapted  to  the  particular  conditions  of 
concern. 


DE^.l.  DOMAIN  DEFINITION  ACIIVITY 


1.  GETTING  STARTED 

Domain  Definition  is  an  activity  of  Domain  Analysis  for  creating  a  Domain  Definition.  A  Domain 

Definition  is  an  informal  description  of  the  systems  in  the  btniness  area  that  form  a  domain.  A  Domain 

Definition  diaracterizes  how  ^ems  in  the  dmnain  are  similar  and  how  they  differ. 

1.1  OaiEcnvu 

The  objectives  of  the  Domain  Definition  Activity  are  to: 

•  Establish  a  conceptual  basis  and  bounds  for  more  detailed  Domain  Analysis 

•  Determine  u^ether  planned  development  and  evolution  of  the  domain  is  viable  relative  to  the 
organisation's  business  objectives 

•  Establish  criteria  which  management  and  engineers  can  judge  s^ether  a  proposed  system 
is  [voperly  within  ^e  domain 

1.2  REQUIRD  iNFORMAnON 

The  Domain  Definition  Activity  requires  the  Domain  Plan. 

13  Required  Knowledge  AND  Experience 

The  Domain  Definition  should  be  developed  by  people  with  a  variety  of  badcgrounds  in  the  business 

area  understuity,  including  engineering,  business,  ai^  management  e]q)erience.  Spedfic  expertise  is 

needed  for: 

•  Broad  business-area  kno^edge:  What  systems  have  been  built;  the  nature  of  tystems  likely 
to  be  requested  and  built;  new  features  and  tedux>logy  that  will  impact  on  customer 
esqpectations. 

•  K-oad  market  awareness:  What  contracts  are  forthomnin^  what  kind  of  competition  there  will 
be  for  those  contracts;  the  long-term  growth  potential  of  this  business  area. 

•  Proposal  develoixnent  mqierience:  What  aspects  of  a  tystem  are  critical  to  winning  a  contract 
proposal  in  this  business  area. 

•  System  develoinnent  and  management  eq)erience:  Size,  cost,  and  schedide  estimation  for 
tystems  in  this  business  area;  an  intuithw  understanding  of  the  tedinical  difficulty  and 
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fea«bility  of  a  given  feature;  knovdedge  of  the  oommon  areas  ctf  confusion  <x  vagueness  in 
requirements  or  high-level  design;  knovdedge  of  the  common  variations  or  changes  to  systems 
in  this  business  area  over  the  ratire  life  ^e,  including  development,  installation,  and 
maintenance. 

2.  PRODUCT  DESCRIPnON 
Name  Domain  Definition 

Ptapose  A  D(»nain  Definition  establishes  the  scope  ofa  domain  and  a  jusdficatitHi  of 

its  economic  viability.  It  provides  a  basis  for  determining,  infornuJly,  whether 
a  system  is  properly  within  that  scope. 

The  Domain  Definition  does  not  answer  detailed  questions  of  sa^,  but 
dearly  indudes  and  exdudes  broad  dasses  of  systems.  Assumptions  of 
commonality  and  exdusion  identify  the  ounmon  features  of  tystems  in  the 
domain,  thereby  establishing  a  famify.  Assumptions  of  variability  identify  how 
tystems  in  the  family  are  distinguished  from  one  another.  Justifiation 
provides  a  basis  for  judging  technical  and  economic  feasibility  and  market 
potential  of  the  domain  to  evaluate  whether  there  is  sufiBdent  confidence  in 
the  viability  of  develof^  the  business  area  as  a  domain. 

Content  A  Domain  Definition  consists  of  the  following  components: 

•  Domain  Sjmopsis.  An  informal  statement  of  the  scope  of  the  domain. 

•  Domain  Glossaty.  Definitions  of  significant  terminology  used  Ity 
experts  in  discussing  needs  and  solutions  in  the  domain. 

•  Domain  Assumptions.  A  description  of  ^at  is  common,  variable,  and 
excluded  among  tystems  in  the  domain. 

•  Domain  Status.  An  assessment  of  the  current  maturity  and  viability  of 
the  domain  relative  to  its  planned  evolution. 

•  L^acy  Products.  A  representative  collection  of  work  products  from 
odsting  tystems  in  the  product  line  whidi  may  be  a  suitable  source  of 
information  and  raw  material  for  develof^  the  domain. 

Hsifieation  •  Every  Domain  Assumption  must  be  endorsed  for  every  customer  type  in 

Criteria  the  customer  base  identified  in  a  Domain  Status. 

•  The  needs  of  all  customer  types  in  the  customer  base  must  be  fiiUy  metby 
the  Domain  Synopsis  and  ^main  Assumptions. 

2.1  Domain  Synopsis 

Piapose  The  Domain  ^opsis  is  an  informal  statement  of  the  scope  of  the  domain.  It 

characterizes  systems  included  in  the  domain. 
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Content 


ADomain  ^nopsis  includes  an  infonnal  duiracterization  of  the  systems  that 
make  up  the  domain. 


Form  and  A  Domain  Synopsis  is  a  simfde  narrative  using  terms  defined  in  the  Domain 

Structure  Glossary.  Example  DEJI.1-1  illustrates  a  fragment  of  a  Domain  Synopsis  for 

the  TLC  domain.  This  fragment  depicts  typical  information  contained  in  a 
Domain  Synopsis  and  the  use  of  terms  from  the  Domain  Qossary. 


The  Traffic  Light  Control  Scrftware  System  flljC)  domain  is  a  family  of  embedded  computer  systems  to  control  the 
operation  oftraffic  lights  at  a  given  intenection.  The  TLC  domain  is  limited  to  controlling  traffic  at  intersections  of  two 
roads  with  at  most  one  road  dead-ending  at  the  intersection,  ^sterns  in  the  TLC  domain  control  traffic  at  the  intersectian 
by  changing  the  indicaton  of  each  traffic  light  (called  a  traffic  li^t  sequence).  Eadt  traffic  light  sequence  is  coordinated 
with  the  other  traffic  lights  in  the  intersection  to  prevent  accidents  sdiile  vehicles  traverse  the  mtersection.  Usually,  a  TLC 
system  generates  its  traffic  light  sequence  based  on  a  clock-generated  cycle  which  may  last  from  one  (1)  to  three  hundred 
(300)seocmds.  The  traffic  light  sequence  generated  from  the  dock  may  be  modified  based  on  signals  fr^  optional  hqxit 
devices. 

One  optional  input  device  is  a  trip  mechanism  buried  under  the  roadway.  Atripmedianism  may  beassodated  with  ehber 
a  left-turn  lane,  a  ri^t-tum  lane  or  a  thru-trafilc  lane.  Input  from  a  trip  mechanism  associated  with  a  left-turn  lane 
amtrds  vdietber  the  left-turn  indicator  of  the  traffic  light  is  turned  on  during  a  traffic  1  ight  sequence.  A  trip  medianism 
associated  with  a  right-turn  signal  may  act  in  an  analogous  manner  for  a  right-turn  signal.  Inputs  from  any  trip  mechanisms 
may  alter  the  traffic  light  sequence.  A  trip  mechanism  b  tx)t  required  for  the  proper  operation  of  the  turn  lane. 

Another  rational  input  device  b  the  pedestrian  crosswalk  push  button.  Thb  input  controb  whether  the  walk/don’t  walk 
mdicator  bon  during  a  traffic  light  sequence.  It  rtuy  also  modify  the  traffic  light  sequence.  A  push  button  b  not  required 
for  the  proper  operation  the  pedestrian  lane. 


Ebample  DE.2.1-1.  Fragment  c^TLC  Domam  Synqpsb 

Verification  •  The  Domain  Syno|»is  must  give  an  intuitive  feel  for  the  definitive 

Criteria  characteristics  of  systems  in  the  domain.  It  should,  in  itself,  adequately 

describe  any  existing  or  potential  ^tem. 

•  A  term  that  could  have  different  meanings  to  different  readers  may  be 
used  in  the  Domain  Synopsis  only  if  it  is  defined  in  the  Domain  Glossary. 

2.2  Domain  Glossary 

Purpose  The  Domain  Glossary  is  a  compendium  of  precise  definitions  for  all  significant 

terminology  used  by  experts  for  discussing  problems  (customer  needs)  and 
solutions  (systems)  in  a  domain.  This  domain  terminology  is  organized  into  a 
taxonomy  of  terms. 

Content  A  Domain  Glossary  has  two  parts: 

•  A  set  of  standard  terms  and  their  definitions 

•  A  list  of  references  to  external  sources  whidi  define  and  elaborate  on 
relevant  topics  and  terminology 
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Fttrmtmd  A  reference  to  an  external  source  is  written  using  an  accepted  documentatkm 

Aruettirv  style  for  a  reference  (e^^  authcv-date).  Standard  terms  are  defined  in 

alphabetical  order  using  the  following  ftwms: 

Ibnn  1  definition  (source) 

Iferm  2  (1)  first  definition  (source);  (2)  second  definition  (source) 

The  source  of  the  term’s  definition  (source)  is  listed  after  the  definition. 
Example  DE.2.1-2  illustrates  a  fragment  of  a  Domain  Glossary  for  the  TLC 
domain.  This  fragment  defects  ^cal  terminology  needed  to  discuss  systems, 
I^oblems,  and  solutions  in  the  TLC  domain. 


Ikm 

DcQaltlon 

CraMrik 

A  specialty  paved  or  mariced  path  for  pedestrians  crossing  a  street  or  road.^ 

Chanaik  Push  Button 

A  monhoring  device  ediidi  allows  a  pedestrian  to  signal  to  the  ^stem  his  presence 
at  a  crosswalk. 

TtjpItorhBni^m 

A  traffic  monitoring  device  used  to  determine  ehether  a  vehide  is  present  in  a  lane. 

‘Baffic  Control 

Ayndironaed  set  of  traffic  light  sequences  ^>eci6edasafiinctioo  of  time  and  trafBc 
monhoring  device  inputs. 

Tkdfie  Light 

A  set  of  indkators  pdaced  at  the  intersection  of  Streets  to  regulate  traffic. 

*BafBBL^t  Cyde 

One  heratioo  through  a  trafiBc  li^t  sequence,  Le..  from  the  display  of  the  red 
indicator  through  to  the  next  diqday  of  the  red  iiklicator. 

Baffie  Light  Sequence 

The  order  in  Miich  a  set  traffic  li^t  indicators  are  displqred  during  a  traffic  cyde. 
'^{Hcally,  this  ordering  is  red,  green,  airiber,  but  other  orderings  are  posable. 

Baflie  Monitoring  Device 

A  device  that  monitors  the  flow  traffic. 

*  BUsater’s  Third  New  International  Dkdooaiy  of  the  En^isfa  Language  Unabridged 

Exain]de  DE2.1<2.  Fragment  of  TLC  DoatainGkwuy 

Itrjflnrten  •  The  Domain  Glossary  must  contain  precise  definitions  of  all  significant 

CrUerim  terminology  used  by  domain  experts  for  discussing  the  requirements  or 

en^eering  of  systems  in  the  domain. 


•  Any  term  used  in  a  definition  that  could  have  different  meanings  to 
different  readers  must  also  be  defined. 
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•  Alliiidepaid«itl]H»edtenmthMaregeiieralizatk>ns,sp6CMlizatk>iis,or 
compcments  of  defined  terms  must  also  be  e3q)licitly  dinned. 

•  Tbrms  defined  in  the  Dcmuun  Glossary  must  be  sufficient  for  a  domain 
expert  to  give  an  accurate  description  of  any  existing  or  potential  system. 

2J  Domain  Assumptions 

Purpam  Domain  Assumptions  desoibe  what  is  common  to  all  systems  in  the  domain 

and  in  what  sign^cantways  those  systems  vary  and  can  be  distinguished.  These 
assumptions  determine,  informally,  \^ether  a  system  is  within  the  scope  of  the 
domain. 

CoMimt  There  are  three  types  of  assumptions: 

•  CbrnmoitofityAssuifipdoiis.  Aset  (tf  assumptions  about  the  diaracteristics 
that  are  common  to  all  tystems  in  the  domain  (commonalities). 

•  VaruAUityAssumf^ns.  A  set  of  assumptions  about  the  characteristics 
that  distinguish  systems  in  the  domain  (variabilities). 

•  JExdhsioiiaiyAjsunyietanr.  A  set  of  assumptions  about  tne  characteristics 
of  systems  that  are  outside  the  scope  of  the  domain  (exdusions). 

Every  assumption  is  composed  of  a  description  and  justification. 

Assumptions  may  also  be  elaborated  with  assodated,  subordiiutte 
assumptions.  For  »ample,  a  commonality  assumption  may  have  specific 
variabilities  associated  with  it  Similarly,  a  particular  resolution  of  a  variability 
assumption  can  be  thought  of  as  characterizing  a  subfamily  of  the  produa 
family.  The  subfamily  then  may  have  additional,  more  specific  commonalities 
and  variabilities  that  further  distinguish  the  members  of  the  subfamily. 

An  assumption  desoiption  and  justification  are  informal  text  Assumptions 
which  elaborate  another  assumption  should  be  presented  in  adjacent 
indented  text.  Examples  DE2.1-3  and  DE.2.1-4  illustrate  fragments  of  some 
commonality  and  variability  assumptions  for  the  TLC  domain.  The 
justification  provides  rationale  on  why  the  domain  engineers  believe  the 
assumption  to  be  valid. 

l^r^kation  •  Commonality  and  variability  assumptions  must  capture  all  important 

Criteria  aspects  that  are  common  to  dl  tystems  in  the  domain  and  the  significant 

ways  in  whidi  these  systems  can  vary.  Exclusionary  assumptions  must  not 
exclude  needed  capabilities. 

•  Systems  must  only  vary  as  implied  by  the  variability  assumptions. 

•  Every  conunonality  assum[>tion  must  apply  equally  well,  without 
qualification,  to  any  system  in  the  dotnam.  ^tems  must  not  violate  a 
stated  commonality,  either  by  occluding  an  induded  feature  in  the  commo¬ 
nality  assumptions  or  by  induding  an  exduded  feature  in  the  exdusioruuy 
assrunptions. 


Form  and 
Simctare 
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•  A  TLC  system  oontnds  the  traffic  light  sequeoces  at  an  mtersectkn. 

JuaHjpeaiUm  The  purpose  of  a  TLC  system  is  to  oontrd  a^ren  traffic  li^  sequesieea  change,  and  the 
interactioas  of  the  traffic  l^ts  at  an  intenectioo. 


•  A  TLX!  system  coordinates  all  traffic  lights  at  an  intersection. 

JuatfflocUbm  Safe  transit  of  interaection  requires  that  streams  of  traffic  not  cross,  e.g.,  east  botmd  traffic 
and  north  bound  traffic  cannot  have  green  mdicators  concurrently. 


•  The  entire  week  is  divided  into  traffic  cycles.  Tlw  traffic  lights  at  the  intersectkn  are  synchronized  based  on 
these  traffic  cycles. 

Justification  Ihffic  patterns  and  loads  vary  over  the  course  (tf  a  day  and  ^  a  week.  Ihe  timing  of  the 
traffic  cydes  must  be  varied  to  deal  with  the  variations  in  the  traffic  load. 


•  A ILC  system  must  process  signals  from  a  trip  mechanism  or  push  button  within  a  specified  time. 

Justijictttion  Smooth  traffic  flow  depends  upon  the  TLC  ^stem  detecting  and  responding  to  requests  to 
a  traffic  light  sequence  in  a  timely  manner. 


Examine  DE.2.1-3.  Fragment  ofTLC  Commonality  Assumptions 


•  All  reviewers  must  agree  that  domain  experts  will  consider  Domain 
Assumptions  to  be  consistent  and  unambiguous,  relative  to  the  definitions 
in  the  Domain  Glossary.  A  term  that  could  have  different  meanings  to  dif¬ 
ferent  readers  may  be  used  in  a  Domain  Assumption  only  if  it  is  defined 
in  the  Domain  CHossary. 

2.4  Domain  Status 

Purpose  Domain  Status  describes  the  current  technical  maturity  of  the  domain  that  the 

organization  has  achieved  relative  to  planned  evolution,  and  assesses  the 
viability  of  evolution.  Of  particular  concern  are  unsupported  variability 
assumptions  (i.e.,  default  commonalities). 

The  Domain  Status  describes  evaluations  that  establish  whether  the  domain, 
as  defined,  will  be  economically  and  technologically  viable.  Qualitative  and 
quantitative  criteria  assess  v^ether  current  development  and  future  evolution 
of  the  domain  will  support  the  organization's  business  objectives. 
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•  An  mtersection  ou^  be  fonned  fixxn  two  through  roeds  (an  X  iotasectiQD),  or  from  one  tfaioii^  rood  and  a 
dead-ending  road  (a  T  interaectioo  ). 

Justification  The  number  of  roads  that  can  meet  at  an  mtersectkm  can  vary  from  intersectkxi  to 
intersection.  At  least  two  roads  must  cross  to  have  an  intersection,  but  mtersectkns  of  three 
or  more  roads  are  ommnon.  The  madceting  department  bdieves  that  the  vast  majority  of 
intersections  are  of  the  T  and  X  variety.  It  has  decided  to  concentrate  on  this  large  subset 
of  traffic  intersections. 


•  The  number  of  lanes  of  trafiSc  on  any  road  approaching  or  leaving  the  mtersection  may  vary.  The  minimum 

number  of  lanes  of  traffic  is  one  (1).  The  maximum  number  is  six  (6). 

Justification  Any  road  brin^g  traffic  into  the  intersection  must  have  at  least  (me  laiK  of  traffic  into  the 
mtersection.  Any  road  leaving  the  intersection  must  have  at  least  one  lane  of  traffic  fr(xn 
the  intersection.  Engineering  has  determined  that  the  hardware  (mmpcments  oi  the  system 
cannot  ocmtrol  more  than  six  lanes  of  traffic  in  a  timely  fashion. 


Any  road  approaching  the  intersection  may  have  a  trip  mechanism  buried  rmder  the  traffic  lanes  to  alert  the 
system  to  the  presence  of  vehicular  traffic  There  may  be  no  trip  mechanism  or  there  may  be  one  (1)  per  traffic 
lane. 

Justification  The  traffic  light  sequence  may  take  into  account  the  presence  or  absence  of  vehicular  traffic 
at  the  intersection. 


•  The  duration  of  a  traffic  oontroi  schedule  will  vary. 

Justification  Traffic  patterns  and  volumes  vary  from  mtersectirm  to  intersection.  Effective  traffic  contrrd 
at  these  intersections  requires  schedules  that  take  these  variations  into  account.  TrafBc 
control  schedules  must  also  vary  to  account  for  differences  in  system  configurations. 


Example  DE.2.1>4.  Fragment  of  TLC  >4riability  Assumptions 

Content  The  Domain  Status  is  an  informal  characterization  of  the  degree  to  which 

Domain  Objeaives  are  satisfied  by  past  development.  It  includes  the  effects 
of  further  planned  development. 

At  a  minimum,  the  Domain  Status  must  include: 

•  An  endorsement  that  the  Domain  Synopsis  and  Domain  Assumptions 
define  economically  viable  domain. 

•  A  concise  statement  that  characterizes  the  confidence  (or  risk) 
associated  with  this  endorsement.  If  possible,  this  should  include  a  jus¬ 
tification  of  the  endorsement  and  a  list  of  major  unresolved  issues  or 
risks  that  may  jeopardize  the  domain’s  viability. 
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DEJ.1.  Doomuii  Dcfinilioo  ActWiy 


Form  and 
Structure 


Depending  on  the  size  of  the  potential  business  area  and  the  attendant 
commitment  to  the  domain,  however,  you  may  need  a  more  detailed  Dcnnain 
Status  consisting  of  some  or  all  of  the  following: 

•  Die  target  customer  base.  Diis  is  a  profile  of  eadi  type  of  customer 
and/or  contract  that  comprises  this  area  of  business.  Each  (nofile  on 
the  list  consists  ofi 

-  Die  name  of  the  customer  (or  contract)  type. 

-  A  short  desaription. 

-  A  list  of  attributes  that  characterize  this  type  of  customer. 
Diese  attributes  fall  into  two  categories:  technical  expecta¬ 
tions  and  administrative  expectations.  Ibchnical  eiqiectations 
are  features  of  the  delivered  products  or  the  process  for  devel¬ 
oping,  testing,  maintaining,  or  delivering  and  installing  the 
products.  Administrative  opectations  are  gross  cost,  profit, 
and  schedule  aspects  of  a  contract. 

-  A  list  of  specific  (potential  or  current)  contracts  and/or 
customers  that  fall  under  this  type. 

•  Agrouping  of  the  different  alternatives  of  variability  assumptions  into 
priority  subsets.  MinimaUy,  there  are  two  subsets:  “must  have”  and 
“nice  to  have.”  A  tystem  of  numerical  weighting  may  be  desirable. 

•  A  statement  of  the  potential  value  of  the  domain.  You  may  need  to 
analyze  alternative  scopes  of  the  domain  separately.  Die  following 
factors  express  the  potential  value  of  a  parti(^ar  scope: 

-  Die  size  of  the  potential  market  (consisting  of  the  target 
customer  base) 

-  Die  planned  share  of  that  market 

-  Die  projected  income  from  that  share 

-  Die  expected  cost  of  supporting  that  market 

-  An  expected  profit  margin  to  justify  the  risk  of  entering  the 
market 

-  A  pricing  structure  for  systems  to  be  produced  that  supports 
the  cost/profit  ocpectations 

Die  maturity  of  a  domain  can  be  expressed  as  limitations  in  satisfying 
variability  assumptions.  Characterize  the  technical  «rpectations  of  the  target 
customer  base  as  the  subset  of  possible  alternatives  of  variability  assumptions 
that  are  supported.  Risks  can  be  mitigated  by  imposing  limits  on  variability 
assumptions. 
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Ikr^fieatioH  •  Every  alternative  of  every  domain  varial^ity  assumption  must  have  an 

Criteria  explidt  (or  overall  group)  economic  justification  from  the  potential  value 

analysis  and/or  an  endorsement  from  the  customer  base. 

•  The  price/capability  of  systems  offered  (as  su{^rted  by  the  domain  value 
analysis  for  a  particular  domain  alternative)  must  compare  sufficiently 
well  against  the  perceived  capabilities  of  the  competition  in  this  business 
area  to  justify  the  anticipated  profit  and  market  share. 

2.5  Legacy  Products 


Purpose 


Content 


Form  and 
Structure 


Verification 

Criteria 


Lega<y  Products  provide  access  to  work  products  from  odsting  systems  that 
may  be  useful  sources  of  information  and  raw  material  for  developing  the 
domain. 

Legacy  Products  consists  of  a  representative  collection  of  work  products  (or 
portions  thereof)  from  existing  systems  in  the  product  line  to  be  supported  by 
the  domain. 

•  Work  products  may  be  physically  stored,  on  paper  or  in  electronic  media, 
or  may  only  be  identified  by  reference  when  sufficiently  accessible  in  this 
way  (e.g.,  in  an  organization’s  local  library  or  in  an  accessible  repository 
set  up  for  another,  existing  domain). 

•  Work  products  are  kept  in  Legacy  Products  in  the  form  in  whidi  they  were 
produced.  Other,  consuming  activities  of  Domain  Engineering  will  copy 
and  excerpt  or  adapt  these  work  products,  as  needed,  in  order  to  create 
reusable  assets. 

•  The  work  products  comprising  the  Legacy  Products  are  organized  in  a 
suitable  manner  to  provide  access  by  other  Domain  Engineering  activities 
to  a  particular  system’s  work  products  or  to  individual  work  products  of  a 
particular  type. 

Each  work  product  in  Legacy  Products  must  come  from  an  existing  system  that 
was  determined  to  be  in  the  domain. 


3.  PROCESS  DESCRIPTION 

The  Domain  Definition  Activity  consists  of  the  five  steps  shown  in  Figure  DE.2.1-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Definition  Activity. 

Step:  Define  the  Domain  Informally 

j^tion  Create  a  description  of  the  domain,  characterizing  key  technical  objectives  of 

included  systems. 


IgXl.Do««mDcfiMik»Acti»iqr 


to 

Domain  Managemtnt 


Figure  DE^l-1.  Domain  Definitioo  Process 

ihipitf  Domain  Plan:  Domain  Objectives 

Result  Domain  Definition:  Domain  Synopsis 

Heurisdcs  •  Start  with  a  one-sentence  description  the  fiunity  of  systons  that  constitutes 

the  domain. 

•  Refine  the  Domain  ^mopsis  to  two  pages,  at  most,  of  intuitive  and  not 
overly-restrictive  text  Impart,  concisely,  an  informal  but  comidete  sense 
of  the  domain  in  the  first  paragraph.  1^  to  focus  on  the  essential  nature, 
scope,  and  variety  of  systems  in  the  domain. 

•  Characterize  the  ^pe  of  problem  that  systems  in  the  domainsolve,  and  the 
external  environment  (i.e.,  devices,  ^tems,  and  users)  with  whidi  ^tems 
interact  Describe  the  observable  behavior  that  ^tems  exhibit  in  solving 
the  problem.  You  might  also  establish  significant  constraints  concerning 
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Ixjw  the  qfstenu  qjcrate  in  tenm  of  peifcMinaiioe,  reUabOity,  or 
concerns. 

•  Cover  the  primary  functions  performed  by  every  system  in  the  domain  and 
any  important  fimcdons  performed  by  only  some  totems.  Maintain  a 
black-box  perspective  vidten  describing  functional  aspects  of  the  system. 

•  Use  terms  defined  in  the  Domain  CMossary  to  keep  the  Domain  Synt^is 
short. 

•  If  the  domain  (e.g.,  process  control  systems)  is  based  on  formal  theories 
that  provide  experts  with  a  common  langm^e  of  communication  about 
problems,  refer  to  those  theories  in  the  Domain  Synopsis. 

Step:  Establish  Standard  Terminology 

Create  definitions  of  all  significant  terms  used  by  domain  «q)erts  in  discussing 
the  requirements  or  engineering  of  systems  in  the  domain. 

Domain  Definition:  Domain  Synopsis 

Domain  Definition:  Domain  Glossary 

•  Maintain  term  definitions  in  alphabetical  order  for  ease  of  reference. 
Provide  cross-referen<»s  to  related  terms. 

•  Use  definitions  from  standard  glossaries  where  possible.  Make  note  of 
such  sources  in  each  definition  for  future  traceability. 

•  Make  definitions  as  predse  as  possible. 

•  Make  sure  that  all  terminology  used  in  the  Domain  Synopsis  is  defined  in 
the  Glossary. 

•  Create  a  structure  that  shows  term  spedalizations  and  relationships 
among  similar  concepts.  This  action  will  reveal  missing  terms  that 
represent  generalizations  or  spedalizations  of  known  terms. 

•  Create  a  structure  that  shows  the  composition  of  terms  and  the 
interrelationship  of  independent  concepts  in  the  formation  of  logical 
structures.  This  will  reveal  missing  terms  that  are  necessary  to  complete 
the  definition  of  other  terms  or  terms  that  tie  other  terms  together  into 
more  complot  concepts. 

Step:  Establish  Domain  Assumptions 

Action  Create  lists  of  the  assumptions  that  allow  you  to  think  of  the  envisioned  set  of 

systems  as  a  family  and  the  assumptions  that  allow  you  then  to  distinguish 
among  them. 


Action 

hiput 

Result 

Heuristics 
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DE2.1.  PoaMia  Defiaitioii  Activily 


Input 

BesuU 

Rmristies 


•  Domain  Definitkm:  Domain  Sym^isis 

•  Domain  De£[niti<Mi:  Dcmuun  Glossary 


Domain  DefinitioiL*  Domain  Assumptions 


•  State  only  those  assumptions  that  affect  the  ^tem  scrftware  and 
associated  delivered  [voducts  (e^.,  documentation,  test  siqiport). 

•  Tb  create  a  preliminary  set  of  assumptions: 

-  Create  a  omnnKmality  assumption  for  eadid]aractar»tics9)ecified  in 
die  D(»nain  ^nopsis  that  is  shared  by  all  systems  in  die  dcxnain. 

-  Create  a  variabili^  assun^ition  for  each  characteristic  specified  in 
the  Domain  Synop^  that  is  not  shared  by  all  ^ems  in  the  domain. 

-  RM'eaditermintheDmnainCHossaty.detaminev^ietharthetain 
indicates  a  commonality  or  a  variifoility  among  ^tems  in  the 
domaiiL  Create  an  assumption  accordin^y. 

•  Make  variability  asstimptions  {vedse  by  indicating  the  type  of  decision  the 
application  engineer  must  make  to  resolve  the  variability.  It  is  not  suffi- 
dent  to  note  only  that  some  diaracteristic  varies.  You  must  establish  how 
much  flexibility  the  aj^tication  engineer  needs  to  characterize  differmt 
systems  adequately. 

•  Elaborate  commonality  assumptions  to  uncover  specific  variabilities 
assumptions  assodated  with  them.  This  will  more  precisely  characterize 
a  subset  of  the  prodtK:t  family. 

•  Elaborate  variability  assumptions  to  find  more  specific  commonality  and 
subsequent  variability  assumptions  that  further  distinguish  membm  of 
the  subfamily. 

•  Compare  the  diaract^isticsttfexislingtystems  to  facilitate  the  idradfication 
of  common  features  and  variatimis. 

•  Consider  diaracteristics  antidpated  for  future  tystems  to  identify 
additional  varialnlity  assuminions. 

•  Look  at  the  mainteiumce  history  of  existing  tystems  for  an  indicatimi  of 
how  tystems  in  the  domain  diaiige  ovm'  their  life  cydes.  The  histories  dt 
these  systems  indicate  likely  variabilities  that  diaracterize  the  evolution  cS 
individual  tystems. 

•  Use  information  on  technological  advancements  that  could  inqMct  the 
development  of  future  tystems  in  the  domain  to  identify  potential 
variations. 


•  Distinguish  between  ^fstens-geiiemiion  time  and  mn-tfane  variatiaas 
adien  developing  asnmqjtioos  idxMtt  variable  a^iects  of  die  doinain. ‘Aem 
a  run-time  variatkm  that  is  daracteristic  of  all  qfstems  in  the  domain  u 
a  commonality. 

•  Use  esdusionary  assumptions  to  clarify  a  domain’s  IxKiodaiy.  Do  not 
enumerate  every  type  of  system  or  fonctim  that  is  outside  tiie  domain. 
Rather,  exclude  eaqdidtly  those  functions  or  characteristics  that  a  domain 
expert  might  incorrectly  assume  to  be  part  a  systm  sdten  reacting  the 
Domain  Synopsis.  Thm,  you  can  answer  the  questkm  ctfvdiether  a  particu’ 
lar  tystem  belongs  within  tiie  dmnain  more  directly  by  died^  tiie 
exclusions.  Exclusions  (rften  result  from  a  viability  anafysis  of  the  domain. 

•  Uncertainties  that  arise  fr(»n  analysis  ofcustomer  requirements  are  (^n 
a  good  source  of  needed  variability.  These  uncertainties  are  questions  that 
customers,  in  the  end,  must  resolve,  but  must  be  asked  or  be  given 
additional  informatiott  to  be  able  to  do  so. 

Step:  Assess  Domain  Status 

Action  Evaluate  the  technical  maturity  of  the  donuun  in  terms  of  Domain  Objectives 

and  plans  for  domain  develo{»nent  and  evolution. 

/ityur  •  Domain  Plan 

•  Domain  Definition:  Domain  Assumptions 

Result  Domain  Definition:  Domain  Status 

Heuristics  Domain  Status  must  result  in  an  endorsement  of  and  commitment  to  a  specific 

domain  scope  (set  of  assumptions).  This  endorsement  may  come  directly  from 
the  intuitions  of  experienced  personnel,  or  it  may  derive  from  a  more 
extensive,  quantitathw  analysis.  Even  in  the  latter  case,  however,  all  estimates 
and  interpretations  will  rely  on  the  best  judgment  of  senior  peojde.  Maity  of 
the  following  heuristics  are  coudied  in  qualitative  terms  to  capture  the  essence 
of  the  decision  being  made,  but  you  can  always  augment  that  decision  by  the 
suggested,  optional  quantitative  analyses. 

Determine  Marketability 

•  Are  tystems  of  this  sort  marketable?  Look  at  the  Domain  Synopsis.  The 
Domain  Synopsis  imi»rts  an  intuitive  feel  that  it  encompasses  tystems  that 
the  profil^  customers  will  buy.  If  not,  identify  what  is  missing  and  add  the 
missing  elements  to  the  Domain  ^opsis. 

•  Do  the  commonality  assumptions  correspond  to  the  essential  needs  of  the 
target  customers?  Are  thty  realty  interest^  in  tystons  that  do  eveiythii^  im- 
{died  by  these  assumptions,  or  may  the  so^  be  reduced?  Conversety,  are 
features  thty  always  require  (possibty  in  variant  forms)  missing?  Change  the 
assumptions  according. 
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•  Do  the  variability  assumptions  represent  the  real  issues  that  determine 
udiether  a  system  addresses  the  individual  needs  of  the  target  custooMrs? 
Are  there  inconsequential  variations  (to  the  target  cusbHners)  that  you  can 
constrain  without  losipg  business?  Are  there  inqxMrtant  dififorences  in  die 
needs  oi  target  customers  that  are  not  cultured  in  die  variabilities?  Change 
the  assumptions  acomdin^. 

•  Do  expectations  of  target  customers  indude  not  only  those  of  the  ^tem 
end-user,  but  also  the  expectations  of  analysts  and  decision  makers  udio 
influence  awarding  of  contracts?  In  particular,  the  administrative 
expectations  should  indude  items  sudi  as  allowable  contract  costs. 

Determine  Implementaldlily  and  Risk 

•  Astraightforward  way  to  reduce  the  number  of  variations  supported  is  first 
to  dedde  what  customers  (or  customer  types)  must  be  retain^  for  viability 
of  the  business.  Then  determine  must-have  and  nice-to-have  variability  al¬ 
ternatives  for  eadi  of  these  customers.  The  aggregation  of  the  must-have 
alternatives  determines  the  minimal  scope  of  your  domain.  Now  you  can 
consider  all  other  proposed  variability  alternatives  with  regard  to  their 
incremental  value  added. 

•  Determine  whether  your  organization  has  a  good  understanding  of  the 
problems  such  systems  are  intended  to  solve,  compared  with  your  competi¬ 
tion,  and  \)riiether  your  organization  has  authoritative  expertise  that  will  be 
committed  to  developing  this  domain. 

•  Determine  whether  your  organization  can  build  sudi  systems.  Consider 
whether  it  has  built  sudi  tystems  in  the  past.  Consider  the  success  of  such 
prior  experience  with  particular  r^ard  to  demonstrated  mastery  of  the 
relevant  software  technology. 

•  If  particularly  difficult  technical  issues  arise,  determine  idiidi  Domain 
Assumptions  are  affected.  If  you  can  reduce  a  high  tedinical  risk  at  the  cost 
of  removing  or  constraining  an  assumption,  consider  how  mudi  domain 
value  is  lost  by  this  reduction  in  scope  and  risk. 

•  Calculate  a  range  for  estimated  tystem  cost,  potential  market,  antidpated 
income,  and  the  like,  representing  your  best-  and  worse-case  e:q}ectations, 
since  good  estimates  are  typically  hard  to  come  by  and  are  speculative  in 
nature. 

Step:  Identify  Legaty  Products 

Action  Identify  existing  systems  in  the  product  line  that  are  considered  representative 

of  the  domain  and  whose  work  products  may  prove  useful  as  sources  of 

information  and  raw  materials  in  develofnng  the  domain. 

•  Domain  Synopsis 
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•  D(Mnain  Assunqjttoos 

Rmdt  Domain  Definition:  Legacy  Products 

Hturisties  •  Use  the  Domain  Synopsis  as  a  guide  to  select  ezistipg  systems  that  are 

within  the  domain  (or  subsystems  that  would  be  parts  of  such  systems). 

•  Based  on  Domain  Assumptions,  identify  wwlc  products  (or  fragments,  if 
appropriate)  from  these  systems  that  reasonably  satisfy  some  or  all  of  Um 
Domain  Assumptions. 

•  Create  a  brief  description  of  the  selected  systems  and  work  products  as  a 
guide  to  their  use  as  a  source  of  information  and  raw  materials  by  other 
Domain  Engineering  activities. 

3.2  Risk  Management 

JRufc  There  is  a  lack  of  critical  expertise. 

Implication  The  Domain  Definition  cannot  be  completed  or  there  is  unacceptably  low 

confidence  in  the  results. 

Mitigation  •  Commit  time  and  resources  to  acquiring  the  expertise. 

•  Restrict  Domain  Assumptions  sufficiently  to  reduce  the  need  for  expertise. 

Risk  The  scope  of  the  domain  may  be  too  narrow,  precluding  useful  variations. 

bnpGcation  •  Opportunities  for  additional  projects  are  lost. 

•  Application  engineering  projects  miss  opportunities  for  reuse. 

NB^gation  Review  the  Domain  Definition  with  management,  experienced  engineers,  and 

potential  customers  to  identify  additional  variations. 

Risk  The  scope  of  the  domain  may  be  too  broad. 

Implication  Resources  are  misapplied  to  solve  an  unnecessarily  general  problem. 

Mitigation  Review  the  Domain  Definition  with  management  and  ocperienced  engineers  to 

identify  under-constrained  Commonalities. 

Ride  Domain  Assumptions  are  too  precise  or  too  vague. 

Implication  Flexibility  is  reduced  unnecessarily,  or  key  decisions  are  left  to  the  discretion 

of  domain  engineers. 

Mitigation  Review  the  Domain  Definition  with  management  and  experienced  engineers 

to  identify  over-  or  under-constrained  Domain  Assumptions. 

4.  INTERACTIONS  WITH  OTHER  ACnVITIES 

4.1  Feedback  to  Information  Sources 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 
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Soune  Domain  Management  Activity 

Rename  Propose  (altonative)  tensions  to  the  Domain  Plan  that  better  match  availaUe 

capabilities.  Con^dete  a  Domain  Definitimi  that  satisfies  Dtnnain  Objectives 
as  dosefy  as  possible. 

Contingeney  The  practices  and  procedures  specified  in  the  Domain  Han  are  either 

ineffective  or  ineffkaoit 

Source  Domain  Management  Activity 

Requmse  Describe  the  ways  in  vtiiich  the  practices  and  procedures  are  either  ineffective 

or  inefficient.  Propose  revisions  to  the  practices  and  procedures  to  make  tiiem 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Condngency  The  Domain  Definition  fails  to  provide  the  capabilities  required  by  the 

Domain  Plan. 

Source  Domain  Management  Activity 

Response  Evolve  the  Domain  Definition  to  be  consistent  with  the  Domain  Plan. 

Contir^ency  The  Domain  Definition  is  incomplete,  ambiguous,  inconsistent,  or  incorrect 

Source  •  Domain  Specification  Activity 

•  Domain  Verification  Activity 

Response  Revise  the  Domain  Definition  to  correct  the  inadequacies. 
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DEL2^.  DOMAIN  SPECIFICATION  ACnVITY 


1.  GETTING  STARTED 

The  Domain  Specification  Activity  is  an  activity  of  Domain  Analysis  for  creating  a  Domain 
Spedfication.  A  Domain  Specification  is  a  precise  characterization  of  the  product  family  denoted  by 
a  domain  and  of  a  process  for  constructing  members  of  that  family. 

The  product  fiumly  is  characterized  from  two  p^^tectives:  how  problems  are  stated  and  how  sdutions 
are  structured.  Problems  are  expressed  in  the  form  of  a  requirements  specification.  Solutions  are  ex¬ 
pressed  in  the  form  of  a  standardized  design.  Both  forms  are  adaptable  to  anticipated  variations  in 
problems  and  solutions. 

1.1  OniBcnvEs 

The  objectives  of  the  Domain  Specification  Activity  are  to: 

•  Create  a  precise  spedfication  of  the  problems  and  solutions  supported  Ity  the  domain 

•  Define  an  Application  Engineering  process  that  is  suited  to  the  needs  of  building  a  product 
in  the  domain 

1.2  RfiQUDffiD  Information 

The  Domain  Specification  Activity  requires  the  Domain  Definition. 

13  Rbquhbd  Knowledge  AND  Experience 

The  Domain  Spedfication  Activity  requires  domain  and  software  knowledge  and  aq)erience  in: 

•  The  process  that  projects  in  the  organization  use  to  construct  an  application  engineering  work 
project 

•  How  systems  in  the  domain  are  constructed,  induding  the  issues  that  application  engineers 
must  resolve  to  create  a  particular  system 

•  The  concepts  and  structures  that  are  convenient  forms  by  vhidi  to  communicate  about  the 
distinguishing  features  of  systems  in  the  domain 

•  The  prindples  and  use  of  appropriate  software  product  develoi»nent  methods 
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2.  PRODUCT  DESCRlPnON 

Name  Domain  Sped£icati<Mi 

Piarpose  The  Domain  Spedfrcation  is  a  specification  fi»  a  product  Eamity  and  an 

associated  ^jf^ication  Engineering  fx-ocess  for  producing  niend)m  of  the 
family. 

CoiOent  A  Dmnain  Specification  consists  of  one  of  each  of  the  ftrilowingoon^nents: 

•  Dedsiom  ModeL  A  Decision  Model  identifies  the  application 
engineering  requirements  and  engineering  decisions  that  determine 
how  members  of  the  product  family  can  vary  (see  Section  DE.2.2.1). 

•  Product  Rt^drmeuts.  Product  Requirements  determine  the  behavior 
and  operational  diaracteristics  of  problems  solved  the  jn-oduct 
family  (see  Section  DE.2.2.2). 

•  i^roeessJieigtaremefnir.ProcessRequiranratsdeterminehow^iplication 
Engineering  is  performed  and  v^idi  work  products  are  produced  as  a 
result  (see  Section  DE223). 

•  Product  Des^u  A  Product  Design  determines  the  structure  and 
composition  of  solutions  provided  by  members  of  the  jn^oduct  family 
(see  Section  DEJ2.2.4). 

Verification  •  All  aspects  of  the  Domain  Definition  are  accurately  captured  in  the 

Criteria  Domain  Specification. 

•  Existing  or  envisioned  ^tems  can  be  described  in  terms  of  the  Domain 

Specification.  No  ^tems  exhibit  behavior  not  indicated  in  the  Domain 

Spedfication. 

3.  PROCESS  DESCRIPTION 

The  Domain  Specification  Activity  consists  of  the  four  steps  shown  in  Figure  DE.22-1. 

3.1  Procedure 

Follow  these  steps  for  the  Domain  Spedfication  Activity. 

Step:  Dedsion  Model  Activity 

Action  Define  the  set  of  requirements  and  engineering  decisions  that  an  aj^cation 

engineer  must  resolve  to  select  an  instance  firom  a  designated  product  family. 

Input  Domain  Definition 

Result  Dedsion  Model 
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Heuristics 


. 'I . 

to 

Domain  Implementation  and 
Domain  Verification 


J 


Figure  DE.2^1.  Domain  Spedficatioo  Rrooess 


•  Define  the  decisions  that  lead  to  expected  differences  among  the  membm 
of  the  family. 

•  A  Decision  Model  for  a  product  family  should  reflect  the  decisions  that 
application  engineers  had  to  make  when  creating  such  products  in 
previous  projects. 

•  The  Decision  Model  for  a  product  famify  should  reflect  the  variability 
assumptions  IGrom  the  Domain  Definition. 
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•  Ensure  that  supported  decisions  are  sufiBdent  to  distinguish  each  emting 
product  from  other  members  of  the  family. 

•  Identify  It^cal  relationships  anK)ng  the  decisions  that  characterize  a 
produa  family  and  use  them  to  structure  the  Decision  Model.  Sudi  rela¬ 
tionships  can  reduce  the  number  and  comi^exity  of  separate  decisions  that 
application  engineers  have  to  make. 


Step:  Product  Requirements  Activity 


Action 

Specify  the  behavior  and  operational  characteristics  of  fwoblems  solved  by  the 
product  family. 

Input 

•  Domain  Definition 

•  Decision  Model 

Result 

Product  Requirements 

Heuristics 

•  Create  a  software  requirements  specification  for  the  product  family. 

•  To  the  degree  that  application  engineering  decisions  change  work  product 
content,  describe  how  content  varies  with  respect  to  those  decisions.  This 
description  will  provide  a  partial  basis  for  explaining  the  meaning  of 
decisions  to  application  engineers. 

Step:  Process  Requirements  Activity 

Action 

Specify  a  standardized  Application  Engineering  process. 

Input 

•  Domain  Definition 

•  Decision  Model 

Result 

Process  Requirements 

Heuristics 

•  Define  the  work  products,  activities,  and  process  of  Application 
Engineering. 

•  Develop  the  form  and  structure  of  the  Decision  Model  as  presented  to  the 
application  engineer. 

Step:  Product  Design  Activity 

Action 

Define  the  design  (i.e.,  composition  and  structure)  of  the  members  of  a 
designated  product  fomily. 

Input 

•  Decision  Model 

•  Product  Requirements 
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•  Domain  Definition:  Legacy  Products 

Result  Product  Design 

Heuristics  •  Create  a  design  for  the  product  family,  induding  a  design  for  eadi  required 

work  product.  An  annotated  outline  is  one  model  of  a  Product  Design  for 
a  document  work  product.  An  information  hiding  structure  and  process 
structure  fi-om  the  ADAPTS®  (Software  Productivity  Consortium  1993) 
design  method  are  models  of  a  Product  Design  for  a  software  work 
product. 

•  A  key  element  of  domain  knowledge  is  how  existing  instances  of  the 
designated  product  family  are  designed.  When  feasible,  derive  the  initial 
Product  Design  for  a  family  by  extracting  the  design  essentials  of  existing 
instances.  Ensure  that  the  composition  and  structure  of  existing  instances 
are  appropriately  reflected  in  the  design. 

•  To  the  degree  that  Application  Engineering  dedsions  change  work 
product  composition  and  structure,  describe  how  composition  and  struc¬ 
ture  vary  with  respect  to  those  decisions.  This  description  will  provide  a 
further,  but  still  partial,  basis  for  explaining  the  meaning  of  dedsions  to 
application  engineers. 

3.2  Risk  Management 

Risk  The  Domain  Specification  does  not  accommodate  a  product '  mily  that  meets 

the  needs  of  the  building  products  in  the  domain. 

Implication  The  domain  will  not  provide  sufficient  opportunities  for  building  unforseen 

products. 

Mitigation  Compare  previously  developed  systems  that  should  be  within  a  product  family 

with  expected  needs  of  the  domain.  Check  that  likely  differences  are 
accommodated. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  to  Information  Sources 

Contingency  The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Domain  Definition  Activity 

Response  Describe  the  inadequacies  in  the  Domain  Definition.  Proceed  with  Domain 

Spedfication,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Domain  Definition. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 
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Source  Domain  Management  Activity 

Refuse  Ftopose  (alternative)  reviaons  to  the  Domain  Flan  ttiat  better  match  awailiAile 

capal^ties.  Con^ete  a  Domain  ^tedficatkm  that  sadsfles  die  Domain  Flan  as 
dos^  as  possiUe. 

Contingency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefiGdent. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  vdiich  the  {M’actices  and  procedures  are  either  ineffective 

or  ineffident  Propose  revisions  to  the  practices  and  procedures  to  noake  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  Suggestions  are  made  for  Domain  Spedfication  changes  to  oqiloit  unforeseen 

opportunities.  For  example,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  when 
the  Domain  Spedfication  was  completed. 

Source  Domain  Implementation  Activity 

Response  •  Revise  the  Domain  Spedfication. 

•  Refer  opportunities  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

Contingency  The  Domain  Spedfication  fails  to  provide  the  capabilities  required  by  the 

Domain  Plan. 

Source  Domain  Management  Activity 

Response  Evolve  the  Domain  Spedfication  to  be  consistent  with  the  Domain  Plan. 

Contit^ency  The  Domain  Spedfication  is  incomplete,  ambiguous,  inconsistent,  or 

incorrect. 

Source  •  Domain  Implementation  Activity 

•  Domain  Verification  Activity 

Responx  Refine  the  Domain  Spedfication  to  correct  any  inadequades. 

Contingency  The  standardized  ^plication  Engineering  process  is  ineffident  or  leads  to 

less-than-ideal  results  for  a  particular  project. 

Source  Project  Support  Activity 
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Contingency 


Source 

Refuse 


Determine  that  the  benefits  of  process  standardizatkm  out«vei||i  the  interem 
of  the  particular  project.  Evolve  the  Apfdication  ^gineering  process  to  refiect 
this  project’s  ei^rience  or  to  be  mwe  flexible  under  the  particular  conditions 
of  concern. 

Sui^rted  {voduct  family  (as  re^vesented  by  its  constituent  work  (noduct 
families)  is  not  useful  for  a  partic^ar  project 

Project  Support  Activity 

•  Determine  that  the  nature  of  the  problem  and  the  consequent  costs  of 
upgrading  the  (M'oduct  family  outweigh  aq)ected  benefits  to  the  particular 
project. 


Evolve  the  domain  engineering  work  product  family  to  reflect  this  project’s 
eaqierience  or  to  be  more  flexible  under  the  particular  conditions  of  concern. 


This  page  intentUmalfy  Ufi  blank. 
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DE^.2.1.  DECISION  MODEL  ACnVIlY 


1.  GETTING  STARTED 

The  Dedsion  Model  Activity  is  an  activity  of  the  Domain  Specification  Adivity  for  jn-oducing  a 
Dedsion  Model.  A  Dedsicm  Model  defines  the  set  of  requirements  and  engineering  decisions  that 
an  application  engineer  must  resolve  to  describe  and  construct  a  deliverable  a^^cation  engineering 
work  product.  A  Decision  Model  is  an  elaboration  of  a  domain’s  variability  assumptions  and  is  the 
abstract  form  (i.e.,  concepts  and  structures)  of  an  ,^)plicati(m  Modeling  Notation  for  a  product  family. 
These  dedsions,  and  the  logical  relationsUps  among  them,  determine  the  variety  of  products  in  the 
domain,  lb  construct  a  product,  these  dedsions  must  be  suffident  to  distinguish  the  product  from  all 
other  members  of  the  family.  The  dedsions  establish  how  work  [products  of  application  engineering, 
induding  software  and  documentation,  can  vary  in  form  and  content. 


1.1  Objectives 

The  Dedsion  Model  Activity  defines  a  set  of  dedsions  that  are  adequate  to  distinguish  among  the 
members  of  an  application  engineering  product  family  and  to  guide  adaptation  of  application 
engineering  work  products. 

1.2  Required  Information 

The  Dedsion  Model  Activity  requires  the  Domain  Definition. 

13  Required  Knowledge  AND  Experience 

The  Dedsion  Model  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  Conceptual  modeling  skills  similar  to  those  needed  to  create  a  database  conceptual  schema; 
see,  for  example,  Kent  (1978)  and  Borgida  (1985) 

•  The  issues  that  experienced  engineers  resolve  when  constructing  systems  in  the  domain 

2.  PRODUCT  DESCRIPTION 
Name  Decision  Model 

Purpose  A  Dedsion  Model  spedfies  the  dedsions  that  the  Application  Modeling 

Notation  must  allow  an  ap^dication  engineer  to  make  in  describing  a  system 
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Content 


Form  and 
Structure 


in  the  domain.  These  decisions  determine  the  extent  of  variation  in  form  and 
content  that  is  possible  in  the  work  products  that  compose  the  products  in  the 
domain. 

Tb  interivet  folly  the  effects  of  decisions  (i.e.,  to  understand  all  prqxrties  of 
the  family  member  identified  a  set  of  decisions)  requires  both  a  Decision 
Model  and  a  Product  Requirements.  The  Decision  M^el  specifies  only  the 
variations  among  members  of  a  fiunily.  It  does  not  spedfy  their  common 
properties.  Product  Requirements  state  the  common  properties,  plus  the 
effects  of  the  decisions  in  a  Dedsion  Model. 

The  Dedsion  Model  work  product  consists  of  three  components: 

•  Decision  Spec^ications.  Spedfications  of  the  set  of  dedsions  that  suffice 
to  distinguish  among  systems  in  the  domain. 

•  Decision  Groups.  A  structuring  of  the  dedsion  spedfications  into 
logical  groups,  based  on  domain-related  criteria. 

•  Decision  Constraints.  A  set  of  constraints  on  the  resolution  of 
interdependent  dedsions. 

A  Dedsion  Model  can  be  represented  by  one  of  the  following  forms: 

•  List  of  questions 

•  Thbular  format 

In  the  question-list  format,  each  dedsion  is  phrased  as  a  question  and  a 
non-empty  set  of  valid  answers.  The  question  identifies  the  dedsion  th&t  an 
application  engineer  must  make.  The  set  states  all  permissible  answers  to  that 
question. 

In  the  tabular  format,  eadi  horizontal  row  in  the  table  expresses  a  dedsion 
spedfication.  The  horizontal  row  is  divided  into  columns.  A  colunrn  identifies 
either  the  dedsion  that  an  application  engineer  must  make,  the  permissible 
answers  for  that  dedsion,  or  a  brief  description  of  the  decision. 

Each  dedsion  and  each  dedsion  group  must  have  a  unique  identifier.  Domain 
engineers  use  this  identifier  when  they  define  adaptable  work  products.  Eadi 
dedsion  group  has  one  list  or  table  that  is  labeled  with  a  mnemonic 
appropriate  to  the  group.  The  group  is  a  set  of  related  decisions.  Each  entry 
is  an  independent  dedsion  that  has  its  own  distinct  mnemonic  label,  a 
specification  of  allowed  values  that  can  resolve  the  dedsion,  and  a  short 
explanation  of  the  meaning  of  the  dedsion. 

If  a  set  of  related  dedsions  is  always  resolved  as  a  unit,  you  can  define  the  set  to 
be  a  composite  dedsion.  Composite  dedsions  are  shown  in  tabular  form  using  a 
combination  of  the  composite  of  indicator  and  indentation.  If  the  ai^lication 
engineer  can  choose  to  resolve  one  (and  only  one)  dedsion  from  a  set  of 
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altonatives,  you  can  define  dte  set  to  be  an  alternative  dedsioa.  Alternative 
decisions  are  shown  in  tabular  form  using  a  axnlnnation  of  die  alternative  of 
indicator  and  indendUion. 

You  can  also  use  a  tabular  format  to  specify  constraints  on  decision  making. 
Dedsion  constraints  may  be  either  structural  or  dependency.  In  both  cases,  a 
decision  group  (the  Dedsion  Group  column)  is  specified  as  the  focus  of  the 
decision  constraint.  A  structural  constraint  is  a  decision  constraint  that  limits 
the  number  of  instances  of  a  decision  group  in  an  Ajif^cation  Model.  \^d 
entries  indude  ezacUy-one,  one-or-more,  zero-or-one,  zero-or-more,  and 
one-for-eadi  X,  vdiere  X  corresponds  to  other  identified  dedsion  groups.  A 
dependenty  constraint  is  a  decision  constraint  that  specifies  how  dedsions 
made  by  an  ai^lication  engineer  affect  subsequent  dedsions. 

Example  DE.2.2.1-1  illustrates  a  firagment  of  a  Dedsion  Model  for  the  TLC 
domain.  The  figure  portrays  dedsion  groups  (e.g.,  Street,  Lane_Group)  and 
their  correspmiding  dedsions,  along  with  appropriate  constraints. 

Verification  •  Every  dedsion  must  be  an  elaboration  of  one  or  more  variabilify 

Criteria  assumptions. 

•  The  Dedsion  Model  must  accommodate  all  variability  assumptions. 

3.  PROCESS  DESCRIPTION 

The  Decision  Model  Activity  consists  of  three  steps  shown  in  Figure  DE.2.2.1-1. 

3.1  Procedure 

Follow  these  steps  for  Dedsion  Model  Activity. 

Step:  Identify  Decisions 

Action  Identify  the  dedsions  that  application  engineers  can  make  to  resolve  all  of  the 

variations  for  a  system  in  the  domain. 

Irgwt  Variabilify  assumptions 

Restdt  Dedsion  specifications 

Heuristics  •  Derive  dedsions  directly  fi:om  variabilify  assumptions.  You  must  have  (at 

least)  one  dedsion  for  each  variation  spedfied  in  the  assumptions.  You  will 
likely  derive  multiple  dedsions  from  a  single  variabilify  assumption;  eadi 
dedsion  is  an  elaboration  of  some  aspect  of  the  basic  variabilify. 

•  Keep  in  mind  that  the  relevant  dedsions  are  those  concerning  fystem 
generation  time,  rather  than  run-time  variation.  If  you  followed  a  similar 
heuristic  in  identifying  Domain  Assumptions,  run-time  dedsions  should 
not  be  an  issue  here.  Your  focus  now  should  be  on  how  members  of  a  prod¬ 
uct  family  differ,  rather  than  on  ways  in  which  a  member  varies  its  behavior 
at  run-time.  However,  if  members  of  a  product  family  have  variable  run¬ 
time  behavior,  then  a  valid  dedsion  may  concern  whether  or  how  a 
particular  member  varies  its  behavior. 
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'fiaffic_Li^_CoDtiolkr  compooed  of 

Sdiedule:  one  of  (Ried^Sdiedule,  RxymiMMble) 

Geometiy:  one  of 

X:  list  leogth  4  of  Street 

T  list  length  3  of  Street 

{designates  the  Qrpe  of  traffic  li^  aequenee  scheduling 
the  HjC  system  must  aocommodate} 

(street  charaderisticB  Cor  an  X  intenectioo} 

(streM  duracteristics  for  a  T  intemection} 

Filed  Schedule:  compoerd  of 

Start  Tone:  (OKX).  23:59) 

Stop.Tune:  ((hOO  .  23:59) 

{start  time  for  this  traffic  light  sequence  scfaedide} 

{stop  time  for  this  traffic  sequence  sdMdule} 

Street:  composed  of 

Name:  identifier 

Right_'Iiim_Lane3:  Lane_Group 

Left_liira_Lanes:  Lane_Group 

Ihrough.Lanes:  Lane_Group 

Pedestrian_Cro6Swalk:  one  of  (Xwalk,  NO_Xwalk) 

Crosswalk_Button:  one  of  (CB,  NO_CB) 

{  streetname) 

{characteristics  for  the  right^iand  turn  lanes} 
{diaracteriatics  for  the  left-hand  turn  lanes} 

{characteristics  for  the  through  lanes} 

{ jrramr*  nf  ■  pwtUatrtan  rmMwllf 

for  this  Street} 

{designates  the  presence  of  a  pedestrian  crosswalk 
pushbutton  for  this  street} 

Lane_Group:  cmnposed  al 

Numbtf_of_Lanes:  numeric(l-2) 

Sensor  one  of  (Sensor,  NO_Sensor) 

{number  of  traffic  lanes  in  this  Lane_GTOiq;>} 

{indicates  adiether  there  is  a  traffic  monitoring 
device  for  each  Une  in  this  Lane_GTOup} 

IVoject_Information:  composed  of 

Name:  identifier 

Mnemonic:  identifier 

{name  for  the  TLC  system} 

{IIjC  ^stem  mnemonic} 

Constraints 

-  The  number  of  throu^  lanes  for  Street(l)  must  be  the  same  as  for  Street(3). 

—  There  can  be  at  most  4  different  schedules  in  the  Rxed_Sd)edule. 

—  A  Through_Lanes  group  must  be  specified  for  each  Street 

Example  DE.2^1>1.  I^gment  of  HjC  Dedsioa  Model 


•  If  a  variability  assumption  asserts  that  a  certain  diaracteristic  of  systems 
in  the  domain  is  variable  without  saying  exactly  how  it  varies,  you  must  de¬ 
termine  exactly  how  the  characteristic  can  vary.  Specify  the  {n-edse  fype  of 
information  that  will  resolve  a  decision. 

•  Avoid  routinely  providing  decisions  that  dictate  arbitrary  implementation 
limits  (e.g.,  maximum  number  of  users)  unless  those  limits  reflect  a  polity 
decision.  Optimization  of  a  system  requires  adequate  flexibility. 


Lev-58 


to 

Product  Requiranents,  Process  Re^unmenls, 
Product  Dedgn,  and  Product  Impknmdadon 


Figure  DE.2.2.1-1.  Decision  Model  PtoocB 

Step:  Stmctare  Dcdsioiis 

Actiem  Organize  decisions  into  lo^cally-related  and  interconnected  groups. 

bipmt  Dedsion  specifications 

Reaitt  Decision  groups 

Heurtstks  •  Eadi  decision  group  should  reiH-esent  a  coherent  and  cohesive  concept  to 

domain  experts.  Such  concepts  usually  have  recognizable  names.  A  ccm- 
cept  may  be  independent  of  other  concepts,  or  may  be  an  aggr^ate  ocm- 
cept  that  unifies  other  simjder  concepts.  In  other  vvords,  a  decision  group 
may  indude  both  individiud  decisions  and  dedsion  groups  as  elements. 

•  Structure  the  set  of  decisions  based  on  the  {vindide  of  separation  of 
concerns  (Dijkstra,  Dahl,  and  Hoare,  eds.  1972).  For  examine,  aeate  a  de¬ 
dsion  group  for  dedsions  that  correspond  to  features  of  a  single, 
physically-distinct  entity. 

•  Group  together  mutually-dependent  dedsions,  i.e.,  those  that  are  unlikety 
to  diange  independently.  Domain  e]q)erts  often  rely  on  a  single  concept 
that  ties  dependent  decisions  together. 

•  Group  together  dedsions  that  repeat  For  examfde,  if  you  need  to  describe 
multiple  types  of  a  particular  device,  the  engineer  may  make  similar 
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decisions  for  eadi  type.  You  can  group  these  decisions  to  create  a  single 
concept  as  a  focus  for  dedsions. 

•  Group  together  decisions  if  they  are  derived  either  from  a  corresponding 
single  variability  assumption  or  from  separate  assumptions  that  were 
grouped  in  the  Domain  Definition.  A  sin^e  assumption  that  motivates 
several  decisions  often  represents  a  single  concept,  \^le  assumption 
groupings  often  suggest  how  domain  experts  organize  their  thoughts  about 
such  systems. 

•  The  principles  of  database  schema  normalization  form  a  valid  model  for 
this  step.  As  is  the  case  with  normalization,  the  goal  here  is  to  identify  and 
organize  a  set  of  concepts  without  redundancy  or  inconsistency. 

•  Define  explicit  logical  connections  between  the  decision  groups.  These 
define  the  relationships  between  the  decision  groups. 

Step:  Identify  Decirian  Constraints 

Action  Define  structural  and  dependency  constraints  that  limit  how  decisions  are 

resolved. 

Input  Decision  groups 

Result  Decision  Model 

Heuristics  •  Define  a  structural  constraint  for  each  decision  group;  specify  limits  on 

when  the  group  can  validly  occur  in  an  Application  Model. 

•  Define  a  dependency  constraint  whenever  one  decision  narrows  the 
resolution  that  the  application  engineer  can  provide  for  another  decision. 

•  You  may  sometimes  create  decision  groups  where  the  cross-product  of  the 
decision  specifications  implies  family  members  that  do  not  exist.  You 
should  examine  existing  systems  and  specify  constraints  that  omit  these 
members  from  the  Dedsion  Model. 

3.2  Risk  MANAraniENT 

KHc  The  Decision  Model  is  inadequate  for  descriptions  of  intended  systems. 

Implication  The  domain  will  not  provide  effective  support  for  planned  projects. 

AStigation  Ify  to  describe  one  or  more  existing  systems  in  terms  of  the  Decision  Model. 

Review  these  descriptions  with  experienced  engineers  to  identify  erroneous 
assumptions  or  tmacceptable  limitations. 

Risk  The  decision  space  is  too  large  or  complex. 

Implication  Effort  required  to  develop  the  Decision  Model  and  subsequent  adaptable 

work  products  will  exceed  a  reasonable  level. 
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WtigatioH  •  Focus  on  a  set  (rf  well-understood  dedstons  and  make  die  assuo^idon. 

eaq^ddy,  that  the  other  decisions  have  fixed  values  (i.e^  tmx^XMrarily 
constrain  them  to  be  commonalities).  Plan  to  relax  these  assum|)ti(ms  in 
subsequent  iterations,  or,  in  extreme  cases,  suggest  that  the  Domain 
Definition  Activity  consider  narrowing  the  domain  scope. 

•  Reorganize  the  dedsion  space  to  achieve  a  more  efifective  separation  of 
concerns. 

4.  INTERACTIONS  WITH  OTHER  ACITVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Domain  Definition  Activity 

Response  Desaibe  the  inadequades  in  the  Domain  Definition  and  suggest  appropriate 

refinements.  Proceed  with  Dedsion  Model,  and  document  any  assumptions 
made  regarding  the  inadequate  portions  of  the  Domain  Definition. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Dedsion  Model  that  satisfies  the  Domain  Plan  as 
closely  as  possible. 

Contingency  The  practices  and  procedures  spedfied  in  the  Domain  Plan  are  either 

ineffective  or  ineffident 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  ineffident  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Dedsion  Model  fails  to  support  all  the  variation  described  in  the  Domain 

Definition. 

Source  •  Product  Requirements  Activity 

•  Product  Design  Activity 

Respotae  Refine  the  Dedsion  Model  to  be  consistent  with  the  Domain  Definition. 

Contingency  The  Decision  Model  is  incomplete,  ambiguous,  or  inconsistent. 
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Sowt* 


Raponse 

Condagenqf 

Source 

Besponae 


•  Product  Requirements  Activity 

•  Process  Requirements  Activity 

•  Product  Design  Activity 

•  Product  Imi^ementation  Activity 

Refine  the  Decision  Model  to  correct  inadequacies. 

The  structure  or  content  of  the  Dedsitm  Model  conflicts  with  dmnain  experts' 
conception  of  an  ^>|^cation  Model. 

Process  Requirements  Activity 

Refine  the  Decision  Model  to  support  an  Aj^cation  Modeling  Notation 
acceptable  to  domain  e^rts. 
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1.  GETTING  STARTED 

The  Product  Requirements  Activity  is  an  activity  of  the  Dtunain  Specification  Activity  for  aeating 
Product  Requirements.  A  requirements  spedfication  describes  needs  that  are  satisfied  by  aeating  an 
Application  Produa.  Needs  are  e3q>ressed  in  terms  of  the  required  behavior  and  operational  environ¬ 
ment  of  an  envisioned  application.  Similarly,  Produa  Requirements  is  a  requirements  specification 
that  is  adaptable  to  the  dedsions  supported  by  the  jxrodua  family’s  Dedsion  Model.The  Produa  Re¬ 
quirements  describes  the  set  of  problems  solved  by  the  members  of  a  produa  family.  By  aj^lying  the 
dedsions  that  charaderize  a  particular  [H’odua  (i.e.,  its  Application  Model)  to  the  Produa  Require¬ 
ments,  a  standardized  desaiption  of  that  produa  is  product.  A  Produa  Requirements  gives  meaning 
to  an  Application  Model  as  a  description  of  a  member  of  a  produa  family. 

1.1  Objectives 

The  objective  of  the  Produa  Requirements  Activity  is  to  define  the  requirements  for  a  produa  family. 
The  spedfication  must  be  adaptable  to  dedsions  allowed  by  the  produa  famitys  Dedsion  Modd. 

1.2  Required  Information 

The  Product  Requirements  Aaivity  requires  the  following  information: 

•  Domain  Definition 

•  Dedsion  Model 

13  Required  Knowledge  AND  Experience 

The  Produa  Requirements  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  The  nature,  purpose,  and  use  of  work  products  for  existing  applications 

•  The  issues  that  application  engineers  must  resolve  in  constructing  applications  in  the  domain 

•  The  concepts  and  strudures  that  are  appropriate  for  describing  the  behavior  and  operational 
environment  of  applications  in  the  domain 

•  The  prindples  and  use  of  an  appropriate  software  requirements  spedfication  method  (e.g., 
informal,  structured,  semi-formal,  or  formal  [Heninger  1980]) 
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2.  PRODUCT  DESCRIPTION 

Name  Product  Requirements 

Purpose  Product  Requirements  specify  the  requirements  of  members  ol  a  product 

family.  Product  Requirements  also  define  the  meaning  of  an  ^^cation 
Model  created  in  accordance  with  the  corresponding  product  family’s 
Decision  Model.  You  can  use  the  Product  Requirements  to  understand  (and 
ezi^ain  to  api^cation  engineers)  the  implications  of  decisions  in  an 
^plication  Model  (vidiidi  describes  the  prt^lem  solved  by  an  api^cation). 

Content  The  Product  Requirements  is  an  adaptable  requirements  spedfication  for  a 

product  family.  A  specification  contains  four  types  of  information: 

•  Concept.  An  overall  characterization  of  purpose  and  objectives. 

•  Context.  A  characterization  of  the  relevant  environment  and 
relationships  within  it. 

•  Content.  A  characterization  of  the  expressed  or  contained  substance, 
meaning  or  behavior,  and  scope. 

•  Constraints.  A  characterization  of  limits  and  demands  on  context  of  use 
or  content. 

As  a  whole,  this  information  is  sufficient  to  characterize  each  particular 
member  of  a  produa  family  as  implied  by  the  dedsions  allowed  by  the  family’s 
Decision  Model. 

Form  and  Product  Requirements  may  be  expressed  in  any  well-defined  form,  for 

Structure  example: 

•  Structured,  informal  text 

•  Assertions 

•  A  formal  or  semi-formal  specification 

The  assertions  form  of  Product  Requirements  is  a  set  of  assertions  that 
descr9>e  the  (black-box)  behavior  of  applications  in  the  domain.  Assertions 
may  be  simple  or  parameterized  to  reflect  dedsions  defined  in  the  Dedsion 
Modd.  Assertions  can  be  structured  into  a  hierarchy  to  fadlitate  separation 
of  concerns. 

For  all  forms,  parameterization  can  be  used  to  express  the  effects  of  dedsions 
on  Product  Requirements.  A  metaprogramming  notation  can  desoibe  text 
sidistitutton,  conditionai  indusion,  and  iteration  over  repetitive  dedsions. 
Example  DE.Z22-1  illustrates  a  fragment  of  a  Product  Requirements  for  the 
TLC  domain.  This  fragment  depnets  a  portion  of  the  content  (e.g.,  externally 
vis9)lebehavior)  and  contend  (e.g.,  inputs  from  the  enviroiunent)  of  systems  in  the 
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out  in  the  following  oon^untioo.  <if  lhtfk_Iig}it_CoBtrolliKG«oaMt(]r  ■  X  thai> 


Strati 


Street4 


Stieet2 


<ebe> 


Stieed 

Streetl 


Street2 


Streets 


<endif> 


Each  trafSc  light  sequence  in  the  inteoectkm  is  coordinated  with  other  trafBc  lights  in  the  mtenectko.  Hie  intersection 
arms  have  the  following  characteristics. 

<forall  streets  S  in  Trafnc_lJght_Controller.Geometry> 

Street  (<S.Name>): 

<if  S.Right.lhm.Lanes  spedfied  then> 

—  <  SJtight_‘nim_L>anes.Num_of_Lanes  >  right  turn  lanes 
<endif> 

<U  S.Left_'nim_Lanes  speciQed  then> 

-  <  S.Left_IVim_Lanes.Num_of_Lanes  >  left  turn  lanes 
<endif> 

<endfor> 


<if  there  exists  at  least  one  Street  such  that  StreetCrosswaIk_Button  =  CBthen> 

The  Crosswalk_Button  device  interrupts  the  TLC  system  each  time  the  crosswalk  button  is  pushed.  The  message  received 
from  this  device  has  the  following  characteristics: 


<endif> 


The  TLC  system  also  has  an  mteiface  to  a  real-time  clock.  The  dock  is  used  by  the  TLC  system  to  determine  when  to  activate 
a  traffic  light  cyde  (in  the  absence  of  any  trip  medianisms  in  the  streets)  and  the  duration  of  eadi  traffic  light  indicator  in 
a  traffic  light  sequence.  A  TLC  system  also  uses  the  real-time  dock  to  keep  track  of  the  current  time-of-day  to  determine 
how  quickly  it  must  respond  to  signals  received  from  trip  mechanisms  or  pedestrian  crosswalk  push  buttcms. 


Example  DE.2.2.2>1.  Fragment  of  TLC  IVoduct  Requirements 


TLC  domain.  This  fragment  also  depicts  the  use  of  parameterization  (in  terms 
of  appropriate  decisions  from  the  product  family’s  Dedsion  Model  shown  in 
Example  DE.2.2.1-1)  to  express  requirements  that  characterize  particular 
members  of  the  product  family.  For  example,  the  blodc  of  text  describing  the 
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message  format  received  from  the  CTOsswalk  button  device  is  only  included  in  the 
Product  Requirements  when  there  is  at  least  one  Street  in  the  TLC  system  whidi 
has  that  device. 

Comment.  A  black-box  description  for  Product  Requirements  reduces  the 
tendency  to  choose  software  design  and  implementation  solutions 
prematurely.  ^  parameterizing  the  description,  it  will  apjdy 
equally  well  to  all  members  of  the  product  family.  Figure 
DE.2.2.2-1  illustrates  how  an  Application  Model  for  a  product  is 
applied  to  a  parameterized  Product  Requirements  to  yield  a 
stamdardized  software-requirements  specification  for  that  product. 

PI  P2  ._  PM 

Application 
Model 
Decisions 
(Dl,  D2, ..,  DN) 


Software  Requirements 

Figure  DE.2.2.2-1.  Instantiatmg  Product  Requirements 

Verification  •  All  implicit  requirements  must  be  an  elaboration  of  one  or  more 

Criteria  commonality  assumptions. 

•  The  Product  Requirements  must  elaborate  all  conunonality  assumptions. 

•  If  decisions  that  characterize  a  particular  particular  system  are  applied  to 
the  Product  Requirements,  the  result  should  be  a  requirements 
specification  that  describes  that  system  correctly. 

3.  PROCESS  DESCRIPTION 

The  Product  Requirements  Activity  consists  of  four  steps  shown  in  Figure  DE.2.2.2-2. 

3.1  Procedure 

Follow  these  steps  for  the  Product  Requirements  Activity. 

Step:  Define  the  Concept 

Action  Describe  overall  purpose  and  objectives  for  the  product  family. 

Input  •  Domain  Definition 

•  Decision  Model 
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I^oduct  Design,  Product  ImplemaUation, 
Donuun  Verifia^on 


iMgure  DE.2.2^2.  IVoduct  Requirements  PKcess 


Result 

Heuristics 


Product  Requirements:  Concept 

•  Select  a  requirements  method  that  best  supports  an  abstract  desoiption 
of  the  product  family. 

•  Describe  an  application's  purpose  and  concept  of  operations.  For 
associated  documents,  describe  objectives  and  provkk  an  overview  of  omtent 

«  Examine  commonality  assumptions  to  identify  additional  aspects  of 
concepts  that  apply  to  all  members  of  the  product  family. 

•  Examine  variability  assumptions  to  derive  additional  aspects  of  concepts 
that  distinguish  particular  members  of  the  product  family.  Capture  these 
requirements  by  parameterizing  concept  descriptions  in  terms  of  the 
appropriate  decisions  from  the  product  family's  Decision  Model. 

•  Examine  Legate  Products  from  the  Domain  Definition  to  derive 
additional  concept  requirements  that  apply  to  all  or  some  members  of  the 
product  family.  For  common  concepts,  determine  whether  these  will  apply 
to  future  members  of  the  product  family.  Desaibe  variations  in  concepts 
in  terms  of  decisions  in  the  product  family's  Dedsion  Model.  If  no  sudi  de¬ 
cisions  exist,  then  decide  whether  you  want  to  extend  the  Dedsion  Model 
to  accommodate  these  requirements  variations. 


Step:  Describe  the  Context 


Action  Describe  the  relevant  environment  and  relationships  for  the  product  family. 

ItV’ti  •  Domain  Definition 

•  Dedsion  Model 
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Result  Product  Requirements:  Context 

Heuristics  •  Describe  the  enviroiunent  (e.g.,  devices,  coimected  systems,  users/roles) 

in  which  an  application  operates.  Also  describe  the  interface  to  that  envi¬ 
ronment  (e.g.,  inputs  from  the  environment,  outputs  to  the  environment). 
For  documents,  describe  their  audience,  expected  benefits,  and  relation  to 
other  work  products. 

•  Examine  commonality  assumptions  to  derive  additional  context 
requirements  that  apply  to  all  members  of  the  product  family. 

•  Examine  variability  assumptions  to  derive  additional  context 
requirements  that  characterize  a  particular  member  of  the  product  family. 
Capture  these  requirements  by  parameterizing  context  descriptions  in 
terms  of  the  appropriate  decisions  from  the  product  family’s  Decision 
Model. 

•  Examine  Legacy  Products  to  derive  additional  context  requirements  that 
apply  to  all  or  some  members  of  the  product  family.  For  common  require¬ 
ments,  determine  whether  these  will  apply  to  future  members  of  the  prod¬ 
uct  family.  Describe  variations  in  context  in  terms  of  decisions  in  the 
product  family’s  Dedsion  Model.  If  no  such  decisions  exist,  then  decide 
whether  you  want  to  extend  the  Decision  Model  to  accommodate  these 
requirements  variations. 

Step:  Derive  the  Contcat 

Action  Describe  the  externally  visible  behavior  and  information  content  of 

applications  in  the  product  family. 

Input  *  Domain  Definition 

•  Decision  Model 

Result  Roduct  Requirements;  Content 

Heuristics  •  Define  an  information  model  of  an  application’s  information  content. 

Describe  the  externally  visible  behavior  of  an  application,  including  con¬ 
ceptual  modes  of  operation  and  functions  that  produce  output  to  the 
environment.  For  documents,  identify  the  topics  to  be  covered. 

•  Examine  commonalify  assumptions  to  derive  requirements  that  apply  to 
all  members  of  the  product  family. 

•  Examine  variabilify  assumptions  to  derive  additional  requirements  that 
characterize  particular  members  of  the  product  family.  Capture  these 
requirements  in  the  Product  Requirements  by  parameterizing  content 
descriptions  in  terms  of  the  appropriate  decisions  from  the  product 
family’s  Decision  Model. 
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Examine  Legacy  Products  of  the  Domain  Definidtm  to  identify  and  extract 
additional  common  and  varying  requirements  for  content  Fm  conunon 
content,  consider  whether  these  requirements  will  aj^ly  to  future  mem¬ 
bers  of  the  product  family.  Describe  variations  in  content  in  terms  of  ded- 
sions  in  the  product  family’s  Dedsion  Model.  If  no  such  decisions  exist 
then  dedde  whether  you  want  to  attend  the  Dedsion  Model  to 
accommodate  these  requirements  variations. 


Step:  Identify  Constraints 


Action 

Input 


Result 

Heuristics 


Describe  limits  and  demands  on  members  of  the  product  family. 

•  Domain  Definition 

•  Dedsion  Model 

Product  Requirements:  Constraints 

•  Describe  environmental  limits  (e.g.,  reliability  and  responsiveness  of 
devices),  performance  demands  (e.g.,  timing  and  accuracy  goals  for  inputs 
and  outputs),  and  design  or  implementation  dictates  (e.g.,  targeting  of 
software  to  operate  on  particular  computers).  Fbr  documents,  describe 
any  formatting  guidelines. 

•  Examine  commonalify  assumptions  to  derive  additional  constraints  that 
apply  to  all  members  of  the  prcxluct  family. 

•  Examine  variabilify  assumptions  to  derive  additional  constraints  that 
characterize  particular  members  of  the  prcxluct  family.  Capture  these  re¬ 
quirements  by  parameterizing  constraint  descriptions  in  terms  of  the 
appropriate  dedsions  from  the  product  family’s  Dedsion  Mcxlel. 

•  Examine  Legacy  Prcxiucts  to  derive  additional  constraints  that  apply  to  all 
or  some  members  of  the  prcxluct  family.  Fbr  common  constraints,  deter¬ 
mine  whether  these  will  apply  to  future  members  of  the  prcxluct  family. 
Describe  variations  in  constraints  in  terms  of  dedsions  in  the  product  fam¬ 
ily’s  Dedsion  Mcxlel.  If  no  such  dedsions  exist,  then  dedde  whether  you 
want  to  extend  the  Dedsion  Model  to  acconunodate  these  requirements 
variations. 


3.2  Risk  Management 


Risk 

Implication 


Mitigation 


Product  Requirements  do  not  capture  all  Domain  Assumptions  accurately. 

A  derived  requirements  spedfication  will  not  accurately  describe  the  problem 
that  the  corresponding  product  family  member  solves. 

Create  an  Application  Model  for  one  or  more  existing  systems  and  derive  their 
respective  requirements  spedfications.  Review  the  spedfication  with 
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customers,  aperienced  engmeers,  and  dcHnain  aq)erts  to  ktoitify  any 
inaccuracies. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feei»ack  TO  Information  Sources 


(kuttingency 

Source 

Refuse 

Contingency 

Source 

Response 

Contit^ency 

Source 

Response 

Contit^ency 

Source 

Refuse 


The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Domain  Definition  Activity 

Describe  the  inadequacies  in  the  Dmnain  Definition.  Proceed  with  Product 
Requirements,  and  document  ai^  assumptions  made  regarding  the 
inadequate  portions  of  the  Domain  Definition. 

The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Domain  Management  Activity 

Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  available 
capabilities.  Complete  Product  Requirements  that  satisfy  the  Domain  Ran  as 
closely  as  possible. 

The  practices  and  procedures  specified  in  the  Domain  Han  are  either 
ineffective  or  ineffident. 

Domain  Management  Activi^ 

Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 
or  ineffident.  Propose  revisions  to  the  practices  and  procedures  that  will  make 
them  more  effective. 

The  Dedsion  Model  is  incomplete,  ambiguous,  or  inconsistent 
Dedsion  Model  Activity 

Describe  the  inadequades  in  the  Dedsion  Model.  Proceed  with  Product 
Requirements,  and  document  ai^  assumptions  made  regarding  the 
inadequate  portions  of  the  Decision  Model. 


4.2  Feedback  From  Product  Consumers 

Contingency  Product  Requirements  fail  to  describe  a  product  family  that  is  consistent  with 

the  Domain  Definition. 

Sowve  Domain  Management  Activity 

Response  Modify  the  Product  Reqtiirements  to  be  consistei't  with  the  Domain 

Definition. 
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CmUbiguiey  Product  Requiremeats  are  incooqdete,  ambiguous,  or  inconsiiteiit 

Sourca  •  Product  Deagn  Activity 

•  Product  Imfdementation  Activity 

Response  Refine  the  Product  Requirements  to  correct  inadequacies. 
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DE.2:2  J.  PROCESS  REQUIREMENTS  ACnVITY 

1.  GETTING  STARTED 

The  Process  Requirements  Activi^  is  an  activi^  of  the  Domain  Specification  Activity  for  creating 
Process  Requirements.  Process  Requirements  is  a  specification  of  a  standardized  Applicatitm  Engi¬ 
neering  process  for  a  domain  and  an  associated  Aj^Iication  Modeling  Notation.  A  {vocess  spedfica- 
tion  tailors  and  standardizes  the  activities,  methods,  and  procedures  by  which  ^)^cation 
Engineering  is  practiced  within  a  domain.  This  process  replaces  omventional,  domain-independent 
approadies  to  software  develoi»nent. 

As  a  part  of  a  standardized  ^plication  Engineering  process,  application  engineers  create  an 
Application  Model  that  describes  a  required  system.  An  Application  Modeling  Notation  defines  the 
form  and  mechanisms  that  application  engineers  can  use  to  describe  and  evaluate  an  Application 
Model  for  products  in  the  domain.  This  notation  must  be  usable  by  engineers  knowledgeable  in  do¬ 
main  concepts  and  must  produce  an  ^plication  Model  that  is  an  accurate  model  of  the  resulting  prod¬ 
uct.  The  information  content  e:q)ressible  with  an  Application  Modeling  Notation  for  a  domain  must 
be  equivalent  to  the  information  content  defined  by  the  Dedsion  Model  for  that  domain.  The 
organization  and  form  of  the  notation,  however,  are  tailored  to  the  needs  of  application  engineers. 

1.1  Objectives 

The  objective  of  the  Process  Requirements  Activi^  is  to  define  a  standardized  process  for  Application 
Engineering  within  a  domain  and  an  accompanying  Application  Modeling  Notation  for  creating  a  |ve- 
dse  description  of  a  required  product.  The  process  should  be  tailored  to  the  needs  of  the  organization 
so  that  established  productivity  (process  effidenty  and  product  quality)  goals  are  most  attainable. 

1.2  Required  Information 

The  Process  Requirements  Activity  requires  the  following  information: 

•  Domain  Definition 

•  Dedsion  Model 

U  Required  Knowledge  AND  Experience 

The  Process  Requirements  Activity  requires  domain  and  software  kno^edge  and  experience  in: 

•  The  conventional  life-cyde  process  of  systems  in  the  domain  and  the  role  of  customers  and 
standards  in  that  process 
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•  How  apfdication  engineers  resolve  issues  in  constructing  systems  in  the  domain 

•  Hie  concepts  and  structures  that  are  convenient  forms  by  which  domain  oqierts  communicate 
concerning  the  distinguishing  features  of  systems  in  the  domain 

2.  PRODUCT  DESCRIPTION 

Name  Process  Requirements 

Purpose  Process  Requirements  define  a  standard  process  that  apf^cation  engineers 

follow  to  develop  and  evolve  ^tems  in  the  dmnain.  The  process  described  in 
the  Process  Requirements  may  be  manual  or  may  incorporate  varying  levels 
of  automation. 

Content  The  Process  Requirements  work  jx^oduct  consists  of: 

•  Process  Spee^ieation.  A  definition  of  the  work  products,  activities,  and 
process  of  ,^>i^cation  Engineering.  For  each  activi^.  Process  Specifi¬ 
cation  describes  its  purpose,  the  work  products  created,  and 
interactions  with  other  activities. 

•  Application  Modding  Notation  Spectfication.  A  description  of  the  form 
of  the  Application  Modeling  Notation.  The  desaiption  of  the  notation 
consists  of: 

-  Pretentations.  The  form  of  each  set  of  logically-related 
decisions  from  the  Decision  Model  that  application  engineers 
tend  to  treat  as  a  unit 

-  Structure.  The  structure  of  the  ^ij^cation  Modeling  Notation, 
^di  organizes  Presentations  into  a  decision  process  based  on 
dependencies  and  constraints  among  decisions. 

The  Process  Specification  defines  the  products,  activities,  and  process  of 
Application  Engineering.  Eadi  application  engineering  work  product  has  a 
spedfied  content  and  form.  The  form  of  a  product  may  be  defined  aqilidtly 
or  by  reference  to  customer  or  industry  standards.  Each  activity  of  ^iplication 
Engineering  is  described  by  its  purpose,  the  work  products  to  be  created,  a 
procedure  that  defines  and  organizes  the  steps  of  the  activity,  and  interactions 
with  other  activities.  The  ^plication  Engineering  process  is  described  as  a  set 
of  Activities  (e.g..  Specify  Model,  Assess  Model)  that  are  to  be  performed  in 
a  spedfied  (partial)  order.  Each  activify  consists  of  a  number  of  Steps  (e.g., 
Spedfy  Platform  and  Start  Simulation).  The  desaiption  of  the  activify 
indudes  a  spedfication  of  the  order  in  which  steps  may  be  performed.  Each 
step  is  spedfied  in  terms  of  a  presentation  that  describe  the  particular 
information  the  apfdicaticn  engineer  sees  during  that  step  and  a  set  of  actions 
that  he  can  perform. 

The  Application  Modeling  Notation  can  be  specified  as  a  set  of  paper  or 
automated  forms  that  allow  apfdication  engineers  to  make  requirements  or 


Form  and 
Structure 


engineering  decisions  about  the  needed  product.  By  completing  these  forms, 
application  engineers  construct  an  Apfdication  Model  for  a  [voduct.  In 
addition,  the  Notation  organizes  the  forms  into  a  network  that  defines  a 
sequence  in  which  aj^ication  engineers  can  address  any  particular  decision. 

The  description  of  an  activity  in  an  ^plication  Modeling  Notation  is  written 
in  terms  of  a  standard  presentation  paradigm.  A  presentation  paradigm 
defines  a  generic  form  in  ^ch  information  may  be  presented  interactively 
and  is  conceived  as  a  notational  aid  for  describing  the  Application  Modeling 
Notation.  Presentation  paradigms  for  simple  decisions  are  textual,  graphical, 
or  iconic.  Presentation  paradigms  for  grouped  decisions  organize  simpler 
presentations  into  aggregate  (possibly  hybrid)  forms  (e.g.,  textual,  graphical, 
tabular). 

Hr^ation  •  All  decisions  specified  in  the  Decision  Model  should  be  accessible  through 

Criteria  the  Application  Modeling  Notation. 

•  The  Application  Modeling  Notation  should  support  only  those  decisions 
that  can  be  expressed  in  some  equivalent  way  in  the  Decision  Model. 

•  The  Process  Requirements  must  oifivce  all  of  the  constraints  specified  in  the 
Decision  Model. 

3.  PROCESS  DESCRIPTION 

The  Process  Requirements  Activity  consists  of  two  steps  shown  in  Figure  DE.2.2.3-1. 

3.1  Procedure 

Follow  these  steps  for  the  Process  Requirements  Activity. 

Step:  Design  a  Process 

Specify  a  process  for  creating  and  evaluating  an  Application  Model  and  the 
generation  of  work  products  from  the  Application  Model.  Define  the  process 
by  organizing  the  Presentations  defined  in  the  Application  Modeling  Notation 
into  activities  and  specifying  ordering  constraints  and  prerequisites  that 
structure  the  process.  Define  the  points  at  which  analyses  may  be  performed 
and  work  products  may  be  produced. 

Domain  Definition 

Process  Specification 

•  Identify  the  deliverables  that  the  Application  Engineering  process  must 
produce.  This  set  of  products  is  determined  by  the  needs  of  customers.  The 
form  and  content  of  each  product  should  be  defined  in  keeping  with  corpo¬ 
rate,  customer,  or  industry  standards,  as  appropriate.  If  an  adequate  stan¬ 
dard  is  not  available  for  any  product,  create  a  standard  for  your 
organization. 


Action 


Input 

Result 

Heuristics 
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IHgure  DE^2L3-1.  Process  Requirements  Process 

•  Identify  additional  (i.e.,  intermediate  or  auxiliary)  work  products  that 
result  from  the  Application  Engineering  process.  These  work  products 
support  the  need  for  quantitative  and  qualitative  analyses  of  deliverable 
work  products  and  the  Application  Engineering  process. 

•  Define  the  activities  to  be  performed  during  the  process  in  terms  of 
necessary  inputs,  expected  results,  and  procedures  for  attaining  those  re¬ 
sults.  Identify  risks  in  attaining  acceptable  results  and  interdependencies 
with  other  activities.  Define  the  checks  to  be  performed  during  the  process 
and  specify  when  they  are  to  be  performed.  Spedfywhat  is  to  be  done  when 
chec^  fail. 

•  The  process  should  be  described  to  a  level  of  detail  that  allows  you  to 
formalize  standard  practice  and  the  engineer’s  past  e]q)erience.  For  exam¬ 
ple,  Project  Management,  Delivery  and  Operation  Support,  and  configu¬ 
ration  management  practices  may  be  based  on  conventional  aq)erience 
with  those  tasks. 

•  Creating  an  Application  Model  and  using  that  ^)plication  Model  to 
create  work  products  are  essential  elements  of  any  Application  Engineer¬ 
ing  process.  As  a  starting  point,  consider  the  prototypical,  iterative  A>* 
plication  Engineering  process  desoibed  in  Section  AE  (consisting  of 
Project  Management,  Application  Modeling,  Application  Production,  and 
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Delivery  and  Operation  Support  activities),  refined  appropriately  to  the 
needs  of  your  projet^. 

Step:  Develop  Application  Modeling  Notation 

Actim  Organize  dedsions  into  a  set  of  presentations  in  terms  of  a  set  of  statKlard 

presentation  paradigms. 

biput  Decision  Model 

Asuft  Application  Modeling  Notation  Specification 

Heuristics  •  Identify  a  set  ofpresentation  paradigms;  consider  the  ways  domain  esperts 

generally  represent  various  problem  facets  in  a  manner  consistent  with  the 
ways  dedsions  are  grouped  in  the  Decision  Model.  Identify  a  set  of  para¬ 
digms  that  are  adequate  to  represent  dedsions  in  all  the  facets  of  a  prob¬ 
lem  descriiHion. 

•  First,  identify  presentations  by  describing  each  decision  group  in  the 
Dedsion  Model  as  a  presentation,  then  describe  the  presentation  in  terms 
of  allowed  dedsions  and  any  auxiliary  (e.g.,  labeling,  layout)  information 
required  by  the  appropriate  presentation  paradigm. 

•  Create  the  structure  of  the  Application  Modeling  Notation  by  considering 
how  presentations  interrelate  (derivable  from  how  dedsion  groups  in  the 
Dedsion  Model  interrelate).  Some  presentations  maybe  meaningful  only 
if  accessed  in  the  context  of,  or  in  combination  with,  other  related  presen¬ 
tations.  These  relationships  determine  a  reasonable  structure  for  the  No¬ 
tation.  The  ideal  structure  for  an  implication  Model  is  one  that  domain 
experts  would  consider  natural  and  appropriate  as  a  model  of  a  system.  Re¬ 
fine  the  structure  by  consulting  with  domain  experts  as  to  how  dedsion 
making  is  best  organized. 

•  Identify  any  analyses  that  the  application  engineer  should  be  able  to 
perform  on  individual  presentations  and  on  the  Application  Model  as  a 
whole,  lb  be  most  effective,  these  analyses  should  provide  insights  into  the 
fimctional  and  operational  characteristics  of  the  desoibed  system  in  terms 
of  alternative  resolutions  of  dedsions,  rather  than  in  terms  of  the  details 
of  generated  work  products. 

3.2  Risk  Management 

Rlric  The  Application  Engineering  process  will  not  meet  all  of  the  needs  of  a  project. 

ImpUcarion  Projects  will  have  to  modify  the  process  in  an  ad  hoc  fashion  and  work  around 

incorrect  assumptions  of  the  Process  Requirements. 

Mrigation  Review  the  process  with  e3q)menoediTOjed  manats  to  oisure  that  it  aioonq»sses 

all  activities  required  a  ixcject,  th^  products  that  custennm  require,  and  those 
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products  that  boi^t  a  project  Violations  in  project  needs  shoudd  be  antidpated  aod 
supported 

Idsk  The  Application  Modeling  Notation  will  not  be  usable  by  ai^catioo 

engineers. 

Implication  implication  engineers  will  have  difficulty  seating  valid  Aj^lication  Models. 

Midgation  Review  the  Notation  with  experienced  engineers  to  ensure  that  it  is 

understandable  and  that  it  uses  terminology  and  notations  familiar  to 
application  engineers. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  to  Information  Sources 

Contingency  The  Domain  Definition  is  incomplete,  ambiguous,  or  inconsistent. 

Soune  Domain  Definition  Activity 

Response  Describe  the  inadequacies  in  the  Domain  Definition.  Proceed  with  Process 

Requirements,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Domain  Definition. 

Contingaicy  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  ActiviQr 

Refuse  Propose  (alternative)  reviaons  to  the  Domain  Han  that  better  match  available 

caf^ilities.  Comi^ete  the  Process  Requirements  to  satisfy  the  Domain  Plan  as 
dosely  as  possible. 

Contingency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 

Source  Domain  Management  Activity 

Response  Describe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  inefficient.  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

Contingency  The  Dedsion  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Dedsion  Model  Activity 

Response  Describe  the  inadequades  in  the  Dedsion  Model.  Proceed  with  Process 

Requirements,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Domain  Definition. 

Contit^ency  The  structure  or  content  of  the  Dedsion  Model  conflicts  with  domain  expert’s 

conception  of  an  Application  Model. 
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Source  Decision  Model  Activity 

^spotae  Describe  the  elements  of  an  acceptable  Apidication  Modeling  Notation  not 

supported  by  the  Decision  Model. 

4.2  Feedback  From  Product  Consumers 

Cattinemcy  The  Process  Requirements  violate  constraints  on  the  implication  Engineering 

process  established  in  the  Domain  Definition. 

Soune  Domain  Management  Activity 

Response  Evolve  the  Process  Requirements  to  be  consistent  with  the  Domain 

Definition. 

Contingency  The  Process  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Process  Support  Development  Activity 

Refuse  Refine  the  Process  Requirements  to  correct  inadequacies. 

Contingency  The  standardized  Application  Engineering  process  is  inefficient  or  leads  to 

less-than-ideal  results  for  a  particular  project. 

Source  ,Project  Support  Activity 

Response  •  Determine  that  the  benefits  of  process  standardization  outweigh  the 

interests  of  the  particular  project. 

•  Evolve  the  Process  Requirements  to  reflect  the  generally-applicable 
insight  of  this  project’s  e:q>erience  or  to  be  adapted  to  the  particular 
conditions  of  concern. 
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1.  GETTING  STARTED 

The  Product  Design  Activity  is  an  activity  of  the  Donudn  Specification  Activity  for  creating  a  Product 
Design.  A  Product  Design  specifies  the  design  for  product  family,  rather  than  for  a  single  product.  A 
design  describes  an  application  that  solves  a  specified  problem.  Similarly,  a  Product  Design  is  a  design 
that  varies  according  to  the  decisions  supported  tty  the  product  family's  Decision  Model.  By  applying 
the  decisions  that  characterize  a  particular  product  to  the  Product  Design,  a  standardized  design  of 
that  product  is  produced. 

1.1  Objectives 

The  objective  of  the  Product  Design  Activity  is  to  CTeate  a  design  for  a  product  family.  The  product 
family's  design  must  satisfy  its  Product  Requirements  and  must  be  adaptable  to  the  decisions  allowed 
Ity  the  family’s  Decision  Model. 

1.2  Required  Informahon 

The  Product  Design  Activity  requires  the  following  information: 

•  Decision  Model 

•  Product  Requirements 

•  Legatty  Products 

13  Required  Knowledge  AND  Experience 

The  Product  Design  Activity  requires  domain  and  software  knoMedge  and  aq)erience  in: 

•  The  principles  and  use  of  an  approjviate  d^gn  method 

•  How  systems  in  the  domain  are  designed,  induding  an  ai^redation  of  typcal  engineering 
tradeoffs  to  be  resolved 

•  The  concepts  and  practice  of  abstraction-based  reuse  (Pamas  1976;  Campbell  1989) 

2.  PRODUCT  DESCRIPTION 

Name  Product  Design 
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Purpose  A  ProdiK:t  Des^o  ^)edfies  the  de^n  ot  mraibers  (tf  a  product  £aiiiify. 

Content  The  Product  Design  consists  of  the  fc^owing  parts: 

•  Product  Arekiteeture.  A  specification  of  the  internal  or^unzaticm  of 
each  apfdication  engineering  wcvk  (voduct  that  can  be  fvoduced  for 
the  fai^y  (see  Section  DE2.Z4.1). 

•  Componait  Des^  A  specification  of  the  design  of  eadi  of  a  set  of 
Adaptable  Components  that  can  be  adapted  to  compose  deliverable 
application  engineering  work  products  for  the  family  (see  Section 
DE.2.2.4.2). 

•  Generation  Dedffu  A  specification  of  how  a  product  family’s 
Application  Model  is  used  to  select,  adapt,  and  compose  Adaptable 
Components  to  oreate  work  products  that  satisfy  the  Product 
Requirements  and  Product  Architecture  (see  Section  DE.2.2.4.3). 

Veryicadon  •  All  aspects  of  Product  Requirements  are  traceable  into  the  Product  De- 

Criteria  sign.  All  variations  in  Product  Requirements  have  equivalent  variations  in 

the  Product  Design. 

•  The  Product  Design  satisfies  the  verification  criteria  appropriate  to  the 
specific  design  method  used  in  oreating  it. 

3.  PROCESS  DESCRIPTION 

The  Product  Design  Activity  consists  of  the  three  steps  shown  in  Figure  DE.2.2.4-1. 

3.1  Procedure 

Follow  these  steps  for  the  Product  Design  Activity. 

Step:  Product  Architecture  Activity 

Action  Create  design  structures  that  characterize  the  internal  organization  of 

members  of  the  product  family. 

In^  •  Product  Requirements 

•  Legaty  Products 

Pesuit  Product  Architecture 

Heuristics  •  Create  multiple  design  structures  (each  portraying  a  different 

perspective)  for  a  product  family. 

•  Ensure  that  the  produa  family’s  Product  Architecture  applies  to  all 
members  of  that  family. 
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Figure  DE.2^4-1.  Product  De^nProoeai 
Step:  Componeet  Design  Activity 

AeUon  Oeate  a  Component  Design  for  each  of  a  set  of  Adaptable  Cmnponoits  diat 

compose  a  pri^uct  family  as  identified  by  the  Product  Architecture. 

bipia  •  Product  Requirements 

•  Product  Architecture 

•  L^at^  Products 

Result  Component  Design 

Heuristics  Ensure  that  the  Component  Design  satisfies  relevant  aspects  of  die  Product 

Ardiitecture  and  Product  Requironmits. 
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St^  Gcaentioa  DMign  Activity 

Aietioji  Specify  a  precise  procedure  of  how  members  of  a  product  family  are  derived 

from  Adaptable  Components  based  on  the  decisions  in  an  Application  Model. 

Input  •  Decision  Model 

•  Product  Architecture 

•  Component  Designs  ^ 

Result  Generation  Design 

Heuristics  •  Decide  how  the  decisions  for  a  product  family  determine  the  form  and 

content  of  application  engineering  work  products. 

•  Specify  the  design  by  describing  how  Adaptable  Components  are  selected, 
adapted,  and  composed  according  to  the  decisions  in  the  work  product 
family's  Dedsion  Model. 

3.2  Risk  Management 
None 

4.  INTERACTIONS  WITH  OTHER  ACnVITIES 
4.1  Feedback  TO  Information  Sources 

Contingency  The  Decision  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Decision  Model  Activity 

Response  Desoibe  the  inadequacies  in  the  Decision  Model.  Proceed  with  Product 

Design,  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Dedsion  Model. 

Contingency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Product  Requirements  Activity 

Response  Describe  the  inadequades  in  the  Product  Requirements.  Proceed  with 

Product  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contie^ency  The  Domain  Plan  cannot  be  satisfied  with  available  tedmical  capabilities. 

Source  Domain  Management  Activity 

Refuse  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Product  Design  that  satisfies  the  Domain  Plan  as 
dosely  as  possible. 
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Contittgmey 

Source 

Response 

4.2  Feedback  From 
Contingency 

Source 

Response 

Contingency 

Source 

Response 

Contingency 

Source 

Refuse 


The  practices  and  {vocedures  specified  in  the  Domain  Plan  are  either 
ineffective  or  inefficient. 

Domain  Management  Activity 

Describe  the  ways  in  whidi  the  fvactices  and  procedures  are  either  ineffective 
or  inefficient.  Propc^e  revisions  to  the  practices  and  procedures  to  noake  them 
more  effective. 

Product  Consumers 

Suggestions  are  made  for  Product  Design  changes  to  e^oit  unforeseen 
opportunities,  e.g.,  a  situation  vdiere  substantial  software  is  made  available  for 
use  in  the  Domain  Implementation  that  was  not  available  \riien  the  Domain 
Specification  was  completed. 

•  Product  Implementation  Activity 

•  Process  Support  Development  Activity 

•  Revise  the  Product  Design. 

•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

The  Product  Design  does  not  satisfy  the  Product  Requirements. 

Domain  Verification  Activity 

Modify  the  Product  Design  to  be  consistent  with  the  Product  Requirements. 
The  Product  Design  is  incomplete,  ambiguous,  or  inconsistent. 

Product  Implementation  Activity 

Refine  the  Product  Design  to  correct  inadequacies. 
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1.  GETTING  STARTED 

The  Product  Architecttire  Activity  is  an  activi^  of  the  Product  Design  Activity  for  creating  a  Product 
Architecture.  An  architecture,  for  a  given  work  fvoduct,  is  one  or  more  design  structures  that  define 
the  internal  organization  of  that  work  product  firom  different  perspectives.  Similarly,  a  Product  Ardii- 
tecture  is  a  description  of  the  intemai  organization  of  a  product  family.  A  Product  Architecture  in¬ 
cludes  the  architecture  of  each  of  the  work  product  families  that  make  up  the  product  family  A  Prod¬ 
uct  /architecture  varies  according  to  the  decisions  supported  by  the  ptoduct  family’s  Dedsion  Model. 
A  Product  Architecture  describes  a  standardized  architecture  for  all  members  of  a  product  family  in 
a  domain.  By  applying  the  decisions  that  characterize  a  particular  product  to  the  Product  Architecture, 
a  standardized  architecture  of  that  product  is  produced. 

For  each  required  application  work  product  family  (requirements,  design,  code,  etc.),  one  design 
structure  must  identify  a  set  of  Adaptable  Components.  Application  engineers  compose  instances  of 
these  components  to  create  an  instance  of  the  work  product.  Depending  on  which  design  method  do¬ 
main  engineer’s  follow,  they  may  also  aeate  other  structures  which  provide  other  views  of  the  behav¬ 
ior  or  interrelationships  of  components.  In  ail  cases,  the  structures  are  in  an  adaptable  form  so  that 
implication  Engineering  can  use  them  to  produce  any  member  of  the  indicated  product  family. 

1.1  Objectives 

The  objective  of  the  Product  Architecture  Activity  is  to  define  an  adaptable  architecture  for  products 
that  can  be  produced  in  Application  Engineering.  Product  Architecture  is  the  design  of  solutions  to 
the  problems  that  Product  Requirements  describe. 

1.2  Required  Information 

The  Product  Architecture  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Legacy  Products 

U  Required  Knowledge  AND  Experience 

The  Product  Ardiitecture  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  The  principles  and  use  of  an  appropriate  software  design  method  (e.g.,  ADARTS  [Software 
Productivity  Consortium  1993]) 

•  How  tystems  in  the  domain  are  designed  and  documented  following  chosen  design  and 
documentation  methods 


•  IQrpical  et^eering  tradeoffii  that  mutf  be  balanced  when  deaigni^  titans  in  die  dcmura 

•  The  concepts  and  practice  of  metaprogrannning  (Campbell  1989) 

2.  PRODUCT  DESCRIPTION 
Name  Product  Architecture 

Purpose  The  Product  Architecture  describes  the  internal  organization  of  members  of 

the  af^lication  engineering  work  {x-oduct  family. 

Qmteia  The  Product  Architecture  consists  design  structures  for  each  application  work 

product  One  of  die  structures  must  identify  die  componoits  diat  make  iq>  eadi  of 
the  members  oi  die  wcvk  product  famify.  Each  structure  ocnisists  o£ 

•  A  set  of  design  elements 

•  A  relation  that  assodates  elements 

For  example,  a  software  requirements  specification  document  is  one  type  of 
application  engineering  work  product  The  domain  engineers  might  choose 
sections  of  requirements  documents  as  design  elements,  and  “subsection"  as 
the  relation  among  these  elements.  This  describes  the  structure  of  a  software 
requirements  specification  document  in  enough  detail  to  allow  its  composition 
from  its  constituent  elements.  The  structures  developed  for  a  particular 
domain  depend  on  the  particular  application  work  products  and  the  design 
method  used  to  produce  them. 

Although  the  Product  Architecture  for  a  particular  product  may  contain 
multiple  design  structures,  there  must  be  one  structure  that  describes  the 
decomposition  of  the  product  into  work  assignments  (e.g.,  modules,  sections). 
The  elements  of  this  structure  correspond  to  components  that  are  to  be 
implemented  by  Adaptable  Components. 

The  onfy  difference  betweoi  die  design  structures  qiedfied  in  the  Product 
Ardiitecture  and  those  qxdfied  in  a  conventional  de^  is  that  the  Product 
Ardiitecture  is  parametoized  and  adaptaUe,  so  that  it  describes  the  fiunify  oi 
products  in  the  domain. 

The  form  for  eadi  structure  of  a  Product  Architecture  is  a  tactual  or  graphic 
network  of  elements  and  relations.  This  representation  is  then  augmented 
with  a  suitable  technology  such  as  metaivogramniing  notation  to  parameterize 
the  structure  for  adaptation  to  variations. 

Eranqdes  DE.22.4.1-1,  DE.Z24.1-2 ,  and  DE22.4.1-3  illustrate  firagments  of  a 
Pxxluct  Ardiitecture  fcx  die  TIjC  dnnain  0X.,  fragn^its  of  the  static  software 
ardiitecture  for  die  product  family,  process  structure  ardiitecture  for  the  product 
ftunify,  and  an  architecture  for  a  DOD-SrD-2167A  Inteifooe  Requirements 
%)ecf5cation  doaonait  wc^  product  famify,  reqiectiv^).  Multqile  structures  are 
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Structure 
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needed  to  fully  describe  the  ardiitecture  of  the  sc^tware  and  documentatitxi  for  the 
product  fEunify.  Notice  that  the  Product  Ardiitecture  of  the  document  is  expressed 
as  an  annotate  outline  \^4iere  each  numbered  heading  (e^  1.  Scope)  avrespcmds 
to  a  section  of  the  work  product  Fteceding  each  architecture  are  the  dedsicms  that 
parameterize  the  respective  architecture.  Hie  oontoit  these  architectures  will  vary 
depending  rni  values  chosen  for  the  respective  decisions.  examine,  in  Examine 
DE22.4.1-3,  Section  33  will  be  indud^  (mfy  vhen  parameter  aosswalk  is  true. 
Otherwise,  this  section  is  omitted. 
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Product  Architecture  -  Process  Structure  of  the  TLC  product  tkalljr 
Instantiatkm  Parameters 

crosswalk  one  (yes,  no)  {Pedestrian  crosswalk  push  button.  A  value  yes  means  that 

the  sc^tware  information  hiding  architecture  must  indude 
components  to  support  the  Pedestrian  Oosswalk  Push  Button. 
A  value  of  no  means  those  compcments  are  not  induded.} 

sensor  oat  of  (yes,  no)  {....) 


Instantiation  Constramts 


Example  DE.2.2.4.1-2.  Fragment  of  TLC  Product  Architecture 

Vilification  •  Each  Product  Architecture  structure  satisfies  the  verification  criteria 

Criteria  established  by  the  specific  design  method  used  in  its  creation. 

•  The  Product  Architecture  defines  all  structures  for  the  software  and  other 
work  products  required  by  the  Application  Engineering  process. 

3.  PROCESS  DESCRIPTION 

The  Product  Architecture  Activity  consists  of  two  steps  shown  in  Figure  DE.2.2.4.1-1. 

3.1  Procedure 


Step:  Identify  Work  Product  Components 

Action  Develop  a  structure  that  desoibes,  as  a  structured  set  of  components,  the 

internal  organization  of  the  products  in  the  family. 
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Product  Architecture  ->  InterfiMe  Requirements  SpedfkatloB  (IRS)  work  product  (hmliy 
Instantiation  Parameters 

crosswalk  one  of  (yes,  no)  (Pedestrian  crosswalk  push  button.  A  value  of  yes  means  that 

the  IRS  must  indude  en^neeiing  requirements  describing  the 
pedestrian  crosswalk  push  button  capability  of  the  TLC  system. 
A  BO  value  means  the  IRS  must  omit  these  requirements.} 

light_schedule  one  of  (fixed,  dynamic)  (Identifier  udrnt  traffic  light  sequence  scfaedulmg  capability  the 

IRS  must  describe.} 

fixed_scbedule  ocxnpositeof  (The  IRS  must  esqpress  the  requirements  for  a  traffic  light 

»..  sequence  as  defined  by  this  parameter.} 


Instantiation  Constraints 

-  Must  provide  values  for  fixed_schedule  when  light_schedule  is  ‘fixed’ 


Interface  Requirements  Specification  Annotated  Outline 

1.  Scope 

2.  ^iplicable  Documents 

3.  Interface  Specification 

',This  section  specifies  the  requirements  for  those  interfaces  to  which  this  IRS  api^ies.} 

3.1  Interface  Diagrams 

(This  paragraph  identifies  the  interfaces  to  which  this  specification  applies.  One  or  more  interface  diagrams, 
as  appropriate,  will  be  provided  to  depict  the  interfaces.} 

3.2  'n.C_to_Qock  interface 

<lf  crosswalk  =  yes  then> 

33  ■ILC_to_Crosswalk_Pushbutton 

(This  paragraph  identifies  the  'ILC_to_Orosswalk_Pushbutton  interface  and  specifies  the  requirements  for 
the  interface  and  for  the  data  transmitted  across  the  interface.} 

<endif> 


4.  Quality  Assurance 

(This  section  shall  always  state  “NONE.”} 


Input 


Result 


Example  DE.2.2.4.1-3.  Hagment  of  ILC  IVoduct  Architecture 

•  Product  Requirements 

•  Legate  Products 

Product  Architecture:  Internal  Organization 
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Conq>onent  Design,  GauntionDe^fft,  Product  Jn^lesnentation, 
Domain  Verification,  and  Process  Support  DeveU^ment 


Figure  DE.2^4.1*1.  IVoduct  AidiitecturelVooess 

Heurisfies  •  The  Process  Requironeits  d^ne  tiie  required  standards  for  the  devdopment 

of  each  work  product  Hh'  sc^tware,  Rroo^  Reqvdranents  define  vt^ikh  design 
method  is  to  be  Mowed,  which  in  turn  determines  die  design  structures  re¬ 
quired.  Using  ADARTS,  therearethreestructures:hifiarinati(»iHiding,I¥o- 
cess,  aid  Dqieaden^.  For  docuinentatk)n,  an  annotated  (ardine,  in  which  each 
sectkm  and  subsectkm  is  listed  as  a  oonqxment,  is  nmnafly  suflScient  as  die  de¬ 
sign  for  the  wcvk  product  Ra*  test  and  ddiviay  siqipc^  a  hierarchical  structure 
is  needed  that  characterizes  each  test  case  or  ddiv^  hmcdon  as  a  oompcxient 

•  Each  wcx^k  product  is  tadcoi  down,  or  deocmqxised,  into  a  set  c^  ccarqxments 
sothattheworkmaQrbepefianiedindqiaidaitl^bymuldpleocanponaitim- 
I^ementcHS.  Using  a  chosm  desi^  method,  a  structure  must  be  created  that  de¬ 
termines  this  decompoaticMi.  Usmg  ADARTS,  die  InfiDrmation  Hidii^ 
Structure  determines  a  ^taUe  deocmyosition  into  oonqxments. 

•  Each  structure  is  parametoizBd  by  a  set  of  decisioDsdiat  characterize  how  it  is 
adapted  to  rqiresent  a  pardcular  system.  A  parameterhed  structure  defines  a 

of  structures.  The  s^  c^  structure  fionilies  must  be  paiameteized  ocxisis- 
toit^,  both  with  each  other  and  widi  the  Roduct  Requirements.  The  ccmteit 
of  each  structure  must  be  ocmsistait  with  die  Roduct  Requireinents. 


•  Anafyze  L^acy  Products;  Icxik  fen:  recurring  patterns  in  dteir  design 
structures.  Recurringpattemssi^gestpcvtioiisc^astructurediat  do  not  vary. 

•  Use  the  Product  Requirements  to  determine  ^riiat  characteristics  are 
common  to  all  ^tems  in  the  domain.  These  characteristics  should  corre¬ 
spond  to  common  structures  identified  in  the  analysis  of  Legacy  Ptcxlucts. 

•  Each  structure  must  be  adaptable  to  requirements  and  design  variations 
among  systems.  Parameterize  the  structure  to  characterize  required 
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variations.  Use  a  metaprogramming  notation  to  record  the  effects  of 
variations.  For  example,  a  conditional  statement  referencing  a  variation 
indicates  that  a  portion  of  a  structure  is  induded  only  for  some  systems. 

Step:  Develop  Other  Structures 

Action  Create  any  other  structures  required  to  define  the  work  produa  fully. 

Inpitt  •  Product  Requirements 

•  Legacy  Products 

Result  Product  Architecture:  Alternate  Structures 

Heuristics  •  The  chosen  design  method  for  software  identifies  other  required  design 

structures.  Using  ADARTS,  these  design  structures  are  the  Process 
Structure  and  the  Dependency  Structure.  Hypertext-based  documents 
would  have  an  analogous  alternative  structure. 

•  Alternate  structures  impose  constraints  on  the  implementation  of  each 
component  of  the  internal  organization.  The  design  method  characterizes 
these  constraints. 

•  Each  structure  must  support  a  subset  of  the  same  variations.  The  internal 
organization  determines  how  these  variations  affect  eadi  component. 
Component  variations  must  account  properly  for  variations  in  relevant 
parts  of  the  alternate  structures. 

3.2  Risk  Management 

Risk  The  Product  Architectiue  will  not  support  all  features  or  variations  in  Product 

Requirements. 

Imjtikation  The  Product  Architecture  is  not  a  correct  solution  to  the  Product 

Requirements. 

Miration  Review  the  Product  Ardiitecture  with  developers  of  the  Product 

Requirements  and  experienced  designers.  Establish  traceability  of  all 
required  features  to  elements  of  the  architecture.  Evaluate  v^ether  variations 
that  characterize  different  products  lead  to  proper  architectural  variations. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contit^ency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Product  Requirements  Activity 
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Describe  the  inadequades  in  tbe  Product  Requirements.  Proceed  with 
Product  Architecture,  and  document  ai^  assumptk>ns  made  rcgardii^  die 
inadequate  portions  of  the  Product  Requirements. 

Cotaingeiuy  The  Domain  Ran  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Respond  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  available 

capabilities.  Complete  a  Product  Ardiitecture  that  satisfies  the  Domain  Plan 
as  closely  as  possible. 

Cotair^eney  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 

Source  Domain  Management  Activity 

Response  DesCTibe  the  ways  in  which  the  practices  and  procedures  are  either  ineffective 

or  inefficient  Propose  revisions  to  the  practices  and  procedures  to  make  them 
more  effective. 

4.2  Feedback  From  Product  Consumers 

Contingency  Suggestions  are  made  for  Product  Ardiitecture  changes  to  oploit  unforeseen 

opportunities.  For  oample,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  when 
the  Domain  Specification  was  completed. 

Source  *  Produd  Implementation  Activity 

•  Process  Support  Development  Activity 

Refuse  •  Revise  the  Product  Architecture. 

•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

Contii^ency  The  Product  Ardiitecture  does  not  satisfy  the  Product  Requirements. 

Source  Domain  Verification  Activity 

Response  Modify  the  Product  Ardiitecture  to  be  consistent  with  the  Product 

Requirements. 

Cot^ngency  The  Product  Ardiitecture  is  incomplete,  ambiguous,  or  inconsistent 

Source  •  Product  Implementation  Activity 

•  Generation  Design  Activity 
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Respotue 


•  Component  Design  Activity 

Refine  the  Product  Architecture  to  correct  itwdeqMScies. 


This  page  intaUumalfyl^  blank. 


DE^.2.4^.  COMPONENT  DESIGN  ACITVITY 


1.  GETTING  STARTED 

The  Component  Design  Activi ^  is  an  activiQr  of  the  Product  Design  Activity  for  aeating  a  Component 
Design.  Tlie  Product  ^diitecture  identifies  a  set  of  Adaptable  Components  that  are  required  to  im- 
I^ement  the  work  products  of  a  product  family.  A  Component  Design  is  a  design  specification  for  one 
ctf  these  Adaptable  Components.  A  set  of  Component  Designs  defines  a  Ubrary  of  Adaptable  Compo¬ 
nents  that  may  be  adapt^  and  composed  to  implement  the  work  products  of  the  product  famity.  Eadi 
component  must  be  designed  to  satisfy  relevant  aspects  of  the  Product  Requirements  and  all  design 
structures  of  the  Product  Architecture. 

1.1  Objectives 

The  objective  of  the  Component  Design  Activity  is  to  produce  a  design  for  an  Adaptable  Component 
that  satisfies  apj^cable  Product  Requirements  in  accordance  with  its  role  in  the  Prc^uct  Ardiitecture. 

1.2  Required  Information 

The  Component  Design  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Ardiitecture 

•  Legaty  Products 

L3  REQinREDlDtOWLEDGEANDEXnCRIENCB 

The  Component  Design  Activity  requires  domain  and  software  knowledge  and  e]q)erience  in: 

•  How  components  of  tystems  in  the  domain  are  designed 

•  The  principles  and  use  of  an  ap{M:opriate  design  method 

•  The  concepts  and  {ivactice  of  abstraction-based  reuse  (Pamas  1976;  Campbell  1989) 

2.  PRODUCT  DESCRIPTION 


Name 


Component  Design 


Aifpose 

Contant 


Form  and 
Structure 


A  COTiponent  Des^  is  a  tpedficttion  for  an  Adapudrfe  CcMnponait  thu  cui 
be  used  to  construct  an  ap^iicatkm  or  associated  work  product 

Each  Component  Design  represents  a  family  ci  components.  A  Cmnponent 
Design  consists  of  two  parts: 

•  Adaptation  Speeifteatbm,  The  Adaptation  Specification  for  an 
Adaptable  Compmient  describes  the  ways  that  the  component  can  be 
tailored  via  a  set  parameters.  Eadi  parameter  has  a  name  and  type 
to  indicate  its  range  of  variations.  Constraints  identify  invalid 
combinations  of  parameter  variations. 

•  Interface  Spee^ficadon,  The  Interface  Specification  describes  the 
desired  characteristics  of  the  imjdementation  of  the  component  The 
exact  content  of  the  interface  specification  is  particular  to  the  compo¬ 
nent  type  and  the  design  method  used,  lb  describe  the  entire  family, 
the  interface  specification  is  parameterized  with  respect  to  the 
variations  in  the  Adaptation  Spedfication. 

The  Adaptation  and  Interface  Specifications  eadi  include  textual  and  tabular 
information.  The  form  of  an  Adaptation  Specification  is  the  same  for  all  types 
of  components  and  includes  the  following  information: 

•  Name.  Name  of  the  Adaptable  Component. 

•  Instantiation  Pcawneters.  Adaptation  parameters  for  the  component, 
induding  the  name,  type,  and  description  of  eadi  parameter. 

•  Instandadon  Constraints.  Constraints  on  the  instantiation  of  the 
Adaptable  Component  (e.g.,  constraints  on  the  legal  combination  of 
parameter  values). 

The  interface  part  of  Ad:  ptable  Components  is  different  for  software  and 
documentation.  The  content  of  the  sofovare  interface  is  spedfic  to  the  design 
method(s)  used  to  create  the  members  of  the  family.  The  following  types  of 
information  are  examples:  definitions  of  interface  programs  (names,  parame¬ 
ters,  parameter  types,  returned  values),  definitions  of  exported  types, 
desoiptions  of  the  effects  of  interface  programs,  asstunptions  about  the 
environment  in  vriiich  the  software  is  to  be  used. 

The  interface  for  a  documentation  component  does  not  require  the  same  type 
of  detailed  information.  It  consists  of  a  brief  statement  of  the  content  of  the 
component  Exam{de  DE.22.4.2-1  illustrates  a  fragment  of  a  Component 
Design  for  the  ILC  domain.  This  design  corresponds  to  one  of  the  adaptable 
components  identified  in  the  Product  Ardiitecture  shown  in  Ea^jde 
DE.2.2.4.1-1.  The  Adaptation  Spedfication  defines  the  adaptation  parame¬ 
ters  for  this  adaptable  component  The  Interface  Specification  is 
parameterized,  where  apjH’Oimate,  in  terms  of  these  adaptation  parameters. 
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CcnpooeiU  Da%a  -  Detennine  ScbeAde 

Tlia  module  detenninet  the  traffic  U^aequenceicfaechdebMed  OB  mode  ti«Mitioonil<»<kfioBd  in  the  requiraBeott 
document 

Adaptation  ^wcificatioa 

Lostantiatian  Fuameten 

achedule  lotofconqiOMteofi 

itait:  (0:00.23:39) 
end:  ((MO.  23:59) 
namfi  identifier 


Inatantiatian  Constraints 

—  There  must  be  at  least  one  schedule  transition  in  die  schedule  list 

Interface  Specification 
Concr^  Operations 

determine_scbedule_transitian  Determines  the  traffic  li^  sequence  scfaedide  that  the  ILC 

qrstem  should  fiafloafnent  and  returns  the  appropriate  indicator. 


current  sdiedule 


Returns  the  current  sdieduie  the  TLC  system  foOowing 


Example  DE.2.2.4.2-1.  Fragment  ofTLCCcnqxmeotDe^a 

Vertfieation  •  The  Component  Design  satisGes  the  vnification  criteria  established  by  the 

Criteria  specific  design  method(s)  used  for  its  aeation. 

•  The  Con^xxient  Design  satisfies  an  structures  die  Product  Architecture. 

•  The  value  for  eadi  parameter  in  an  Adaptation  Specification  either  is 
derivable  firmn  the  Decision  Model  or  has  a  find,  default  value  for  all 
instances  of  the  component  family. 

3.  PROCESS  DESCRIPTION 

The  Component  Design  Activity  consists  of  two  steps  shown  in  Hgure  DE.2.2.42-1. 

3.1  Procedure 


Follow  these  steps  for  the  Component  Design  Activity.  Domain  engineers  perform  these  steps  for 
eadi  Adaptable  Component  de&ed  in  the  internal  organization  of  the  Frodua  Architecture. 

Step:  Define  Component  Adaptation  Spedficatkm 

Action  Identify  the  variations  that  parameterize  the  Adaptable  Conqionent,  and 

record  constraints  on  legal  combinations. 

Input  •  Product  Ardiitecture 


Result 

Heuristics 


. 1 . 

to 

Can^)oiunt  ImpUmmtadon, 
OenemtionDetisti,  Domain  Vaification, 
Product In^fUmtnUttUm,  andProcta 
SrqrportDavtir^munt 


IHgure  DE.2^4^1.  Compoaent  Design  Brooess 

•  Product  Requirements 

•  Legacy  Products 

Component  Design:  Adaptation  Specification 

•  Identify  components  in  the  Product  Architecture  that  have  the  same  form 
in  all  instances  of  the  domain.  These  components  have  no  associated  varia* 
tions  (i.e.,  they  are  not  adaptable).  You  must  stOl  provide  an  interface 
spedfication,  but  you  may  omit  the  Adaptation  Spe^cation. 

•  The  adaptation  spedficaUon  of  a  component  may  be  determined  by 
identifying  ^di  roles  the  component  must  serve  in  the  design,  determin¬ 
ing  whidi  adaptations  are  required  so  that  it  can  fulfill  these  roles,  and  de¬ 
vising  a  set  of  parameters  that  can  be  used  to  indicate  desired  adaptations. 

•  Examine  Legaty  Products  to  determine  variations.  Concentrate  on 
semantic,  rather  than  syntactic,  distinctions.  However,  unless  you  are  will¬ 
ing  to  reengineer  work  products,  you  may  need  to  define  variations  based 
on  ^tactic  distinctions  as  well. 
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•  Determine  necessary  component  adaptations  by  analyzing  the  Product 
Requirements  to  see  how  the  component  must  vary  to  satisfy  relevant 
requirements.  In  practice,  you  should  try  to  use  both  approaches. 

•  Decisions  that  parameterize  components  must  derive  from,  but  need  not 
be,  the  decisions  identified  in  the  Decision  Model.  In  general,  there  is  a 
many-to-many  relationship  between  Decision  Model  decisions  and  Com¬ 
ponent  Design  parameters.  You  may  use  whatever  dedsions  most  natural¬ 
ly  specify  variations  among  members  of  the  family  defined  by  an 
Adaptable  Component. 

Step:  Specify  Component  Interface 

Action  Specify  the  requisite  properties  for  the  implementation  of  each  component. 

Input  •  Product  Architecture 

•  Component  Design:  Adaptation  Specification 

Result  Component  Design:  Interface  Specification 

Heuristics  The  properties  that  you  must  specify  depend  on  the  type  of  component  and  the 

design  method  used.  Parameterize  each  component  interface  with  the 
decisions  from  the  component’s  adaptation  specification  so  that  it  describes 
all  instances  of  the  component. 

3.2  Risk  Management 
None 

4.  INTERACTIONS  WITH  OTHER  ACTTVITIES 
4.1  Feedback  TO  Information  Sources 

Contingency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Product  Requirements  Activify 

Response  Describe  the  inadequades  in  the  Product  Requirements.  Proceed  with 

Component  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contingency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activify 

Response  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  match  available 

capabilities.  Complete  a  Component  Design  that  satisfies  the  Domain  Plan  as 
closely  as  possible. 
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Comtit^eney 


Source 

Response 

Condngency 

Source 

Response 

4.2  Feedback  From 
Contu^auy 

Source 

Raponse 

Contingency 

Source 

Response 

Contingency 

Source 

Response 


The  ivacticn  and  (vooedures  ^)edfied  in  the  Domain  Han  are  eitho- 
ineffective  or  inefiSdent 

Domain  Management  Activity 

Describe  the  ways  in  whidi  the  practices  and  procedures  are  either  inefifective 
or  inefiGdent  Propose  revisions  to  the  practices  and  {procedures  to  make  them 
more  effective. 

The  Product  Ardiitecture  is  incom[dete,  ambiguous,  or  inconsistent. 

Product  Architecture  Activity 

Describe  the  inadequades  in  the  Product  Architecture.  Proceed  with 
Component  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Ardiitecture. 

Product  Consumers 

Suggestions  are  made  for  Component  Design  dianges  to  exploit  unforeseen 
opfxirtunities.  For  example,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Implementation  that  was  not  available  vdien 
the  Com|X)nent  Design  was  completed. 

•  Product  Implementation  Activity 

•  Process  Supjxirt  Development  Activity 

•  Revise  the  Comjxinent  Design. 

•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

The  Com|X)nent  Design  does  not  satisfy  the  Produa  Requirements. 

Domain  Verification  Activity 

Modify  the  Comimnent  Design  to  be  consistent  with  the  Product 
Requirements. 

The  Component  Design  is  incomplete,  ambiguous,  or  inconsistent. 

•  Component  Implementadmi  Activity 

•  Generation  Design  Activity 

Refine  the  Component  Design  to  correct  inadequades. 


DE.2^.43.  GENERATION  DESIGN  ACTTVITY 


1.  GETTING  STARTED 

The  Generation  Design  Activity  is  an  activi^  of  the  Product  Design  Activity  for  aeating  a  Gennatkm 
Detign.  A  Generation  Design  is  a  specification  of  producti(»  procedures  that  an  applkatkm  engiiwN  uses 
to  produce  deliveraUe  apj^cation  engineering  work  products.  A  Generation  De^  d^ines  a  transfin-- 
mation  (or  mapping)  from  an  Apfdication  Model  that  describes  a  product  to  the  equivalmt  application 
engineering  work  products.  For  ea^  jqiplication  engineoing  work  pitxluct,  a  Generatkm  Design  ^xdfies 
how  to  select  and  adapt  Adaptable  Gompcments  according  to  decisions  in  an  ^}f^cation  Model  and  to 
compel  them  according  to  the  internal  organization  of  that  work  product  in  the  Product  Ardiitecture. 
The  Generation  Design  Activity  is  performed  for  each  work  [voduct  that  comprises  the  product  frunfly 
specified  tty  the  Product  Requirements. 

1.1  OajEcnvES 

The  objective  of  the  Generation  Design  Actmty  is  to  produce  a  specification  for  the  production 
procedures  that  can  be  used  to  produce  application  engineering  work  products  for  a  member  of  a  prod¬ 
uct  family  through  reuse  of  Adaptable  Components.  The  spedfication  establishes  a  correspondence 
between  an  ^plication  Model  and  equivalent  dcHnain  engineering  work  products  that  im{4anent  the 
intent  of  the  mt^el  correctly. 

1.2  Required  Information 

The  Generation  Design  Activity  requires  the  following  information: 

•  Dedsion  Model 

•  Product  Ardiitecture 

•  Component  Designs 

13  Required  Knowledge  AND  Experience 

The  Generation  Design  Activity  requires  domain  and  software  knowledge  and  operience  in: 

•  How  work  products  of  tystems  in  the  domain  are  designed 

•  The  prindples  and  use  of  the  design  method  used  for  the  Product  Ardiitecture 

•  The  concepts  and  i^actice  of  abstraction-based  reuse  (Pamas  1976;  Campbell  1989) 
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2.  PRODUCT  DESCRIPTION 


Name 

Purpose 

Content 


Form  and 
Structure 


Generation  Design 

A  Generation  Design  is  a  specification  for  a  prcxluction  procedure  for  aeating 
deliverable  application  engineering  work  products. 

A  Generation  Design  relates  the  dedsions  firom  the  Decision  Model  to  the 
elements  of  a  work  product's  internal  organization  defined  in  the  Product 
Architecture.  A  Generation  Design  consists  of  three  mappings: 

•  Architecture  MappU^.  The  Architecture  Mapping  is  a  desoiption  of  the 
relation  between  decisions  in  the  product  family’s  Decision  Model  and 
the  decisions  of  the  corresponding  adaptable  Frcxluct  Architecture. 
This  mapping  describes  how  values  for  the  Product  Architectme’s  de¬ 
cisions  are  determined  from  values  of  dedsicms  in  the  Decision  Model. 
As  a  result,  the  Architecture  Mapping  defines  the  internal  organiza¬ 
tion  of  a  work  product  that  describes  a  member  of  the  product  family 
based  on  decisions  in  the  Decision  Model  (i.e.,  from  an  Application 
Model). 

•  Component  Mapping.  A  Component  Mapping  is  a  description  of  the 
relation  of  each  element  of  the  organizational  structure  to  an  Adapt¬ 
able  Component  that  implements  that  element.  This  mapping  defines 
how  each  component  of  a  work  product  is  to  be  product. 

•  Decision  Mumping.  A  Decision  Mapping  is  a  desoription  of  the  relation 
between  decisions  in  the  product  family’s  Decision  Model  and  the 
instantiation  parameters  in  the  adaptation  spedfication  of  a  Compo¬ 
nent  Design  for  eadi  work  product  component.  This  relation  describes 
how  values  for  the  instantiation  parameters  are  determined  from  val¬ 
ues  of  decisions  in  the  product  family’s  Decision  Model. 

There  is  a  Generation  Design  for  eadi  supported  work  product.  The 
Architecture  Mapping  is  represented  as  a  statement  for  each  instantiation 
parameter  of  the  work  product’s  Product  Ardiitecture.  The  statement 
contains  a  pairing  between  an  instantiation  parameter  and  an  expression.  The 
expression  to  determine  the  value  to  assign  an  instantiation  parameter  is 
described  in  terms  of  decisions  in  the  product  family’s  Dedsion  Model.  The 
expression  may  involve  iteration  over  a  group  of  decisions  or  conditional 
testing  of  one  or  more  dedsions. 

The  Dedsion  Mapping  representation  is  similar  to  the  Architectrire  Mapping, 
except  that  the  instantiation  parameters  come  from  the  adaptation 
spedfication  of  the  Component  Design  for  the  work  product. 

The  Component  Mapping  is  represented  as  a  ’’use”  statement  If  the 
expression  bracketing  the  use  statement  is  True,  then  the  use  statement 
describes  which  Adaptable  Component  contains  the  needed  implementation. 
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The  expression  is  usually  des^ibed  in  terms  of  dedsions  in  the  product 
family’s  Decision  Model.  However,  if  the  Adaptable  Component  is  always 
used,  then  an  expression  of  I^ue  is  sufBdent  to  describe  this  situation. 

Examples  DE.2.2.4.3-1  and  DE.2.2.4.3-2  illustrate  fragments  of  a  Generation 
Design  for  the  TLC  domain.  These  depict  one  way  of  representing  the 
expressions  discussed  for  Ardiitecture,  Component,  and  Dedsion  Maj^ing. 
The  dedsions  used  the  metaprogranuning  notation  come  directly  from  the 
Decision  Model  shown  in  Example  DE.2.2.1-1.  The  parameters  on  the 
lefthand  side  of  the  “=”  statements  in  the  Architecture  and  Dedsion  Mapping 
come  from  Examples  DE.22.4.1-1,  DE.2.2.4.1-3,  and  DE.2.2.4.2-1,  respec¬ 
tively. 


Generation  Design  —  Static  Software  Architecture  for  the  TLC  product  family 
Architecture  Mapping 

crosswalk  =  <lf  there  is  a  street  S  that  has  a  Qrosswa]k_Button  »  CB  thcn>  yes 
<else>  no 
<endif> 


Component  Mapping 
Determine  Schedule 

use  adaptable  component  Determine_Sdiedule_']ransition 

Decision  Mapping 

Determme_Schedule_'fiansition 

schediUe  =  (  <foralI  S  in  Fixed_Schedule.Schedule> 

(  start  =  <S.Start_Tlme>, 
end  =  <S.Stopjnme>, 
name  =  <S.Namc>, 

....) 

<endfor> 

) 


Verification 

Criteria 


Example  DE.2.2.43-1.  Fragment  of  ILC  Generation  Design 

•  The  Generation  Design  spedfies  mappings  that  will  produce  application 
work  products  which  exhibit  the  internal  organization  specified  in  the 
Product  Architecture. 

•  The  Generation  Design  spedfies  mappings  that  produce  application  work 
products  which  satisfy  the  Product  Requirements  (i.e.,  the  mappings  are 
consistent  with  Product  Requirements  variation). 

•  All  variabilities  allowed  by  dedsions  are  properly  represented  as  product 
variations. 

•  The  effects  of  variabilities  among  work  products  are  mutually  consistent 
(i.e.,  all  mappings  are  consistent). 
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Oeneratioe  Design  -  Interface  Requiren>eats  SpedScatioo  work  product  family 

Architecture  Mapping 

crosswalks 

<tf  there  is  a  streat  S  that  has  a  CkossiraBc_Biitton  ■  CB  thMi>  jfcs 

<else>  no 

<em&f> 

ligbt_sdiedule  = 

<if  the  'DrafPc_Iight_Controlkr.Scfae<iBk  b  Bxed  theB>  fhed 
<elae>  dynamic 

<ciidif> 

Compooent  Mapping 

Dedsion  Mapping 

Example  DE.22.4J-2.  BragmentofnX^Generatioa  Design 


3.  PROCESS  DESCRIPTION 

The  Generation  Design  Activity  consists  of  two  steps  shown  in  Figure  DE.2.2.4.3-1. 


to 

GenemUmt  InqAer.tenta&on, 
Process  Suf^xjrt  Development,  and 
Domain  Vertficadm 


FiguK  DE.2^43>1.  Generatkm  Design  Process 
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3.1  Procedure 

Step:  Define  Werk  Product  Structure 

Action  Define  how  decisions  in  the  Decision  Model  affea  the  structure  of  the  wcvk 

product. 

/ifMir  •  Dedsion  Model 

•  Product  Architecture 

Result  Generation  Design:  Architecture  and  Component  Mappiqgs 

Heuristics  •  It  is  sufGdent  to  define  the  work  {voduct  structure  as  a  mafqxng  from  the 

Decision  Model  to  the  internal  organization  of  the  Product  Architecture 
for  the  work  product.  The  internal  organization  defines  the  oonq)onents 
that  are  required  to  implement  the  work  product  This  mapf^  deter¬ 
mines  whidi  elements  of  the  Product  Architecture  are  implemented  for  a 
particular  Application  Model. 

•  The  Product  Architecture  determines  (conditionally  and  iteratively)  how 
components  of  eadi  work  product  are  to  be  derived  from  Adaptable  Com¬ 
ponents  (i.e.,  the  component  mapping  is  provided  implidtly  the  Produd 
Architecture).  The  Generation  Design  should  not  modify  that  mapping. 

•  Represent  this  mapping  in  metaprogramming  notation  associated  with 
components  in  the  Product  Architecture.  The  mapi^  is  defined  in  terms 
of  dedsions  in  the  Decision  Model  and  determines  Aether  (one  or  more 
of)  the  associated  component(s)  should  be  included  in  the  prt^uct  created 
for  a  given  ^plication  Model.  This  mapping  is  formed  ^  analyzing  the 
Product  Architecture  and  noting  conditions  that  must  be  true  if  a  particu¬ 
lar  component  is  to  be  included.  If  a  component  is  always  included  in  the 
product,  metaprogramming  notation  is  not  required. 

•  Several  Adaptable  Components  might  be  used  to  implement  a  sin^e 
Product  ArcUtecture  component,  depending  on  dedsions  in  the  .^>plica- 
tion  Model.  In  this  case,  use  a  conditional  in  the  Component  Mapping  to 
qualify  the  assodation  between  the  Product  Ardiitecture  and  Adaptable 
Components,  thus  indicating  vlien  a  particular  Adaptable  Component  is 
used. 

Step:  Define  Component  Adaptation 

Action  Define  a  mapping  from  the  dedsions  in  the  Dedsion  Model  to  adaptations  of 

the  Adaptable  Components  referenced  by  the  Component  Ma|^g. 

Ii^ut  •  Dedsion  Model 

•  Component  Design 
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•  Generation  Design:  Component  Mapping 

Rgsub  Generation  Design:  Decision  Mapping 

Heuristics  When  a  particular  Component  Design  is  to  be  used  to  imfdement  a  particular 

component  in  the  Produa  Ardiitecture,  the  variability  of  the  Adaf^ble 
Component  (i.e.,  its  parameterization)  must  be  realized  in  terms  of  decisions 
from  the  Decision  Model.  Define  the  value  of  eadi  parameter  (by  name)  as 
a  derivation  from  Decision  Model  decisions. 

3.2  Risk  Management 

Bisk  The  Generation  Design  will  not  produce  correctly-strvictured  work  products. 

Implication  Application  Production  will  not  produce  acceptable  application  engineering 

work  products. 

AHtigation  Derive  work  product  structures  from  the  Generation  Design  for  Application 

Models  of  familiar  systems  and  review  the  result  with  experienced  engineers 
to  determine  whether  the  result  is  acceptable. 

4.  INTERACTIONS  WITH  OTHER  ACTTVITIES 

4.1  Feedback  TO  Information  Sources 

Conrit^ency  The  Decision  Model  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Decision  Model  Activi^ 

Response  DesCTibe  the  inadequacies  in  the  Decision  Model.  Proceed  with  Product 

Architecture  and  document  any  assumptions  made  regarding  the  inadequate 
portions  of  the  Decision  Model. 

Contingency  The  Product  Requirements  are  incomplete,  ambiguous,  or  inconsistent. 

Source  Product  Requirements  Activity 

Response  Describe  the  inadequacies  in  the  Product  Requirements.  Proceed  with 

Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Requirements. 

Contir^ency  The  Domain  Plan  cannot  be  satisfied  with  available  technical  capabilities. 

Source  Domain  Management  Activity 

Respond  Propose  (alternative)  revisions  to  the  Domain  Plan  that  better  matdi  available 

capabilities.  Complete  a  Generation  Design  that  satisfies  the  Domain  Plan  as 
closely  as  possible. 

Contingency  The  practices  and  procedures  specified  in  the  Domain  Plan  are  either 

ineffective  or  inefficient. 
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Smote 

Response 


Contingency 

Source 

Response 


Continffssey 

Source 

Response 


Domain  Management  Activity 

Describe  the  ways  in  which  the  i»actices  and  {vocedures  are  either  ineffective 
or  inefficient.  Propose  revisions  to  the  practices  and  (vocedures  to  make  them 
more  effective. 

The  Product  Ardiitecture  is  incomplete,  ambiguous,  or  inconsistent 
Product  Ardiitecture  Activity 

Describe  the  inadequades  in  the  Product  Architecture.  Proceed  with 
Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Product  Ardiitecture. 

The  Component  Design  is  incomplete,  ambiguous,  or  inconsistent 

Component  Design  Activity 

Describe  the  inadequades  in  the  Component  Design.  Proceed  with 
Generation  Design,  and  document  any  assumptions  made  regarding  the 
inadequate  portions  of  the  Component  Design. 


4.2  Feeoikack  From  Product  Consumers 

Contingency  Suggestions  arc  made  for  Generation  Design  changes  to  exploit  unforeseen 

opportunities.  For  example,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Etomain  Implementation  that  was  not  available  when 
the  Generation  Design  was  completed. 

Smace  Generation  Implementation  Activity 

Response  •  Revise  the  Generation  Design. 


Contingency 

Source 


Contingacy 

Source 

Response 


•  Refer  to  Domain  Management  for  future  planning. 

•  Reject  the  changes  due  to  conflicts  with  the  Domain  Definition. 

The  Generation  Design  does  not  satisfy  the  Product  Requirements. 

Domain  Verification  Activity 

Modify  the  Generation  Design  to  be  consistent  with  the  Product 
Requirements. 

The  Generation  Design  is  incomplete,  ambiguous,  or  inconsistent. 

Generation  Implementation  Activity 

Refine  the  Generation  Design  to  correct  inadequades. 
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1.  GETTING  STARTED 

Domain  Verification  is  an  activity  of  Domain  Engineering  for  ensuring  the  correctness,  consistencty, 
and  completeness  of  domain  engineering  work  products.  Both  fwmal  and  informal  tedmiques  may 
be  ap{di^  to  the  domain  engineering  work  products  to  verify  these  properties.  Domain  Verification 
is  an  independent  verification  activity  p^ormed  separately  fitnn,  and  in  addition  to,  the  verification 
performed  as  part  of  each  Domain  E^ineerii^  Activity. 

The  Donuun  Verification  Activity  is  motivated  tty  the  same  coiuxm  that  motivates  IV&V  in  a 
conventional  software  develoixnent  process;  namely,  that  engineers  involved  in  develojang  a  work 
product  cannot  objectively  jtu^e  the  quality  of  that  work  product  Independent  validation  of  the  do¬ 
main  engineering  {Mroduct  from  the  perspective  oi  client  projects,  is  conducted  in  the  Domain  Vdida- 
tion  step  of  the  Project  Suf^rt  Activity. 

Domain  Verification  establishes  the  correctness,  oonmtency,  and  completeness  of  domain 
engineering  work  products.  These  terms  have  a  {vectse  meaning  in  the  context  of  this  activity.  The 
concept  of  correctness  is  that  of  relative  correctness.  Similarly,  the  concept  of  completeness  is  that  of 
relative  completeness.  A  work  {noduct  is  said  to  be  correa  (complete)  with  respect  to  some  oiteria 
or  to  a  more  abstract  representation  of  the  entity  the  work  {voduct  describes.  For  examine,  the  Prod¬ 
uct  Imfdementation  can  be  said  to  be  correcx  (oomfdete)  with  respect  to  the  Product  Requirements. 
Consistent,  on  the  other  hand,  is  a  term  that  applies  to  a  ct^ection  of  related  work  products  (at  the 
same  level  of  abstraction)  that  form  a  whole.  Tlvo  jx-oducts  are  consistent  v^en  tht  ohibit  the  in¬ 
tended  interrelationships.  For  oample,  the  Product  Architecture,  Component  Design,  and  Genera¬ 
tion  Design  work  products  are  strongly  interrelated,  and,  therefore,  mutual  consistemty  is  an 
important  property  for  these  work  jnoducts. 

1.1  OaiEcnvEs 

The  objective  of  Domain  Verification  is  to  independentfy  evaluate  the  quality  of  domain  engineering 
work  products. 

1.2  Required  iNFOKMAnoN 

Donudn  Verification  requires  the  following  information: 

*  Domain  Definition 

•  Domain  Specification 
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•  Dcmudn  Incrementation 

•  Dmnain  Flan:  Practices  and  Procedures 

13  REQuntED  Knowledge  AND  Experiencb 

The  Domain  Verification  Activity  requires  domain  and  software  Imovrfedge  and  e3q)erienoe  in: 

•  AfCH’ojniate  software  verification  techniques 

•  How  to  systematically  plan  and  perform  software  verificatimi 

2.  PRODUCT  DESCRIPTION 

There  are  no  Synthesis  work  products  produced  during  Domain  Verification. 

3.  PROCESS  DESCRIPTION 

The  Domain  Verification  Activity  consists  of  three  steps  shown  in  Hgure  DE33-1. 


Rgure  DE.2J-1.  Domtin  \^aificatioo  ftooes 

3.1  Procedure 

Step:  Verity  Domain  Definition 

Acti/m  Verify  the  correctness,  consistent,  and  oomiTeteness  of  the  Domain 

Defidtion. 

Input  •  Domain  Definition 

•  Domain  Flan:  Practices  and  Procedures 
Beait  None 

Heuristics  •  Verify  that  the  [rnrts  of  the  Domain  Definition  are  correct  and  oomfdete 

with  respect  to  the  guidance  fn-ovided  in  their  respective  activity 
descriptions. 
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•  Verily  that  the  putsch  the  Domain  DefinitkMi  are  ocmrect  with  reflect  to 
any  specific  quality  attributes  required  oi  them  in  the  Practkes  and 
Froce^es  portion  of  the  Domain  Plan. 

•  Verify  that  the  Dcunain  ^nopsts.  Domain  dossaiy,  and  Dmnain 
Assumptions  are  mutually  consistent. 

•  Use  the  verification  criteria,  established  for  the  Dmnain  Definitkm  in  its 
activity  description,  as  guidance  in  verifying  the  Dmnain  D^nition. 

•  Use  static  analysis  techniques  (e.g..  formal  inspectkms,  reviews,  anafysis 
tools)  to  verify  the  Domain  Definition.  These  techniques  are  appropriate 
because  the  Domain  Definition  is  typically  represented  in  document  fmm. 

Step:  Verify  Domain  Specification 


Aaion 

Input 


Rauk 


Heuristies 


Verify  the  correctness,  consistency,  and  completeness  df  the  Domain 

Specification. 

•  Domain  Definition 

•  Domain  Specification 

•  Domain  Han:  Practices  and  Procedures 

None 

•  Verify  that  the  parts  of  the  Domain  Specification  are  correct  and  oomi^ete 
with  respect  to  the  guidance  provided  in  their  respective  activify 
desoiptions. 

•  Verify  that  the  parts  of  the  Domain  Specification  are  conect  with  respect 
to  ai^  spedfic  qualify  attributes  required  of  them  in  the  Practices  and 
Proc^ures  portion  of  the  Donuun  Plan. 

•  Verify  that  the  Process  Requirements,  Product  Requirements,  and 
Product  Design  are  consistent  with  the  Decision  Model.  This  means  that 
these  work  {voducts  only  reference  decisions  in  the  Decision  Model  and, 
conversely,  all  ap|4icable  decisions  in  the  Decision  Model  are  refiected  in 
the  work  {woducts. 

•  Verify  that  the  Product  Ardiitecture,  Component  Design,  and  Generation 
Design  are  mutually  consistent 

•  Verify  that  the  Product  Design  is  correct  and  complete  with  respect  to  the 
Product  Requirements. 

•  Verify  that  the  Process  Requirements  is  correct  and  complete  with  respect 
to  the  assumptions  about  ^e  Application  Bagineering  process  in  the  Do¬ 
main  Definition.  The  ^^cation  En^neering  process  is  normally  not 
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eqjUdtIy  described  in  the  Dcxnain  D^nition,  tnit  the  Domain  Definitioa 
will  tyfMcally  constrain  tx^t  is  an  aoceptabl^  Application  Engineaiflg 
proc^. 

•  Verify  that  the  Product  Requirements  and  Product  Derign  are  correct  and 
comi^ete  with  respect  to  the  representation  of  the  Product  Family  in  the 
Domain  Synopsis  and  Domain  Assumptions  parts  of  the  Domain 
Definition. 


•  Use  the  verification  mteria,  established  for  the  Domain  Specification 
work  products  in  their  respective  activity  descriptions,  as  guidance  in 
verifying  the  Domain  Spedfication. 


•  Use  static  analysis  tediniques  (e.g.,  formal  inspections,  reviews,  analysis 
tools)  to  verify  the  Domain  Spedficatimi.  These  techniques  are  af^opriate 
because  the  Domain  Spedfication  is  typicalfy  reinresented  in  document  fivm. 
If  parts  oi  the  Domain  Spedfication  are  represented  in  an  executable  form, 
the  use  of  dynamic  anal^  tediniques  may  be  appropriate. 

Step:  Verify  Domain  Implementation 

Aethn  Verify  the  correctness,  consistency,  and  completeness  of  the  Domain 

Implementation. 

hvut  •  Domain  Spedfication 

•  Domain  Implementation 

•  Domain  Plan:  Practices  and  Procedures 

Residt  None 


Heuristics 


•  Establish  the  criteria  thatyou  expect  the  Domain  Implementation  to  meet 
before  you  try  to  verify  it.  Identify  analysis  that  you  can  perform  to  ensure 
that  the  Domain  Implementation  is  correct  with  respect  to  the  Domain 
Specification.  Your  plan  should  minimally  establish  verification  objectives 
and  describe  a  strategy  for  meeting  those  objectives. 

•  Verify  that  the  parts  of  the  Domain  Implementation  are  correct  and 
com{dete  with  respect  to  the  guidance  provided  in  their  respective  activify 
descriptions. 

•  Verify  that  the  parts  of  the  Domain  Imfdementation  are  correct  with 
respect  to  ai^  spedfic  qualify  attributes  required  of  them  in  the  Practices 
and  Procedures  portion  of  the  Domain  Plan. 

•  Verify  that  the  Process  Support  and  Product  Implementation  are  mutually 
consistent. 

•  Verify  that  the  Component  Implementation  and  the  Generation 
Implementation  are  mutually  consistent 
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•  Verify  that  the  Process  Support  is  correct  with  respect  to  the  Process 
Requirements. 

•  Verify  that  documents  and  automation  that  make  up  the  Process  Support 
are  engineered  in  a  way  that  adequately  addresses  human  factors  con¬ 
cerns.  For  examfde,  you  should  establish  that  the  implication  Engineering 
Environment  portion  of  Process  Suj^rt  has  the  qualities  of  usability, 
adequate  performance,  and  tolerance  of  user  errors. 

•  Verify  that  the  analyses  that  the  Process  Sui^rt  allows  to  be  performed 
on  Application  Models  produce  correct  results. 

•  Verify  that  the  Product  Implementation  is  correct  and  complete  with 
respect  to  the  Domain  Spedfication.  The  requirements  for  the  Product 
Implementation  are  represented  in  the  Product  Requirements  portion  of 
the  Domain  Specification.  The  internal  organization  for  the  Product  Im¬ 
plementation  is  represented  in  the  Product  Design  portion  of  the  Domain 
Specification. 

•  Verify  that  work  products  produced  using  the  Process  Support  have 
expected  properties.  Do  this  ^  resolving  the  decisions  of  the  product  fami¬ 
ly’s  Dedsion  Model,  producing  the  work  products  corresponding  to  that 
model,  and  then  verifying  that  the  work  products  have  the  expected 
properties.  Specuicaily: 

-  Verify  that  the  work  products  produced  by  the  Process  Support  are 
correct  and  complete  with  respect  to  the  Product  Requirements 
and  Product  Design  of  the  product  family  (appropriately  instan¬ 
tiated  with  the  dedsions  from  the  Dedsion  M^el). 

-  Verify  the  usabilify  and  correctness  of  the  Delivery  Support.  This 
should  be  established  through  direct  inspection  and  by  using  the 
delivery  support  to  install/deliver  the  Application  Product. 

A  good  strategy  for  selecting  work  products  to  produce  is  to  try  to  build  all 
or  part  of  Legacy  Products  that  are  within  the  intended  scope  of  the 
domain. 

•  Use  the  verification  criteria,  established  for  the  Domain  Implementation 
work  products  in  their  respective  activity  desoiptions,  as  guidance  in 
verifying  the  Domain  Implementation. 

•  Use  conventional  verification  techniques  that  are  appropriate  to  the  task 
of  verifying  the  Domain  Implementation.  Static  analysis  tediniques  (e.g., 
inspections)  are  appropriate  for  static  representations  of  the  Domain  Im¬ 
plementation  (e.g..  Application  Engineering  User’s  Guide).  Dynamic 
analysis  tediniques  (e.g.,  testing)  are  appropriate  for  (tynamic  aspects  of 
the  Domain  Implementation  (e.g.,  automated  support  for  specification, 
analysis,  and  product  generation). 
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3J  Risk  Management 

Ride  The  aiteria  used  to  evaluate  the  domain  engineering  work  products  will  be 

unduly  influenced  by  the  final  content  and  form  of  the  work  jn’oducts 
themselves. 

bnpUcadon  The  effectiveness  of  the  verification  effort  will  be  reduced. 

Mitigqdem  Define  acceptable  levels  of  correctness,  completeness,  and  consistency  for 

each  domain  engineering  work  product  prior  to  examining  it. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Condngeney  The  Domain  Definition  is  incorrect,  inconsistent,  or  incomplete. 

Source  Domain  Definition  Activity 

Response  Precisely  communicate  how  the  Domain  Definition  is  incorrect,  inconsistent, 

or  incomplete. 

Condt^ency  The  Domain  Specification  is  incorrect,  inconsistent,  or  incomplete. 

Source  Domain  Specification  Activity 

Response  Precisely  communicate  how  the  Domain  Specification  is  incorrect, 

inconsistent,  or  incomplete. 

Contingency  The  Domain  Implementation  is  incorrect,  inconsistent,  incomplete. 

Source  Domain  Implementation  Activity 

Response  Precisely  communicate  how  the  Domain  Implementation  is  incorrect, 

inconsistent,  or  incomplete. 

4.2  Feedback  From  Product  Consumers 

None 
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DE3.  DOMAIN  IMPLEMEKTATION  ACTIVITY 

1.  GETTING  STARTED 

Domain  Implementatioa  is  an  activity  of  Domain  En^eering  for  imi^ementing  i^oduct  and  process 
support  for  application  engineering  projects  in  a  business  area.  The  Domain  Imi^ementation  must 
satisfy  the  Domain  Specification  aeated  by  Domain  Analysis.  Product  support  consists  of  a  set  of  pro¬ 
duction  procedures  and  associated  Adaptable  Components  that  can  be  used  to  aeate  standardized 
work  products  for  members  of  the  inroduct  fai^.  Process  support  consists  of  procedures, 
documentation,  and,  optionally,  automation  that  define  a  standard  ^^cation  Engineering  process. 

1.1  Objectives 

The  objectives  of  the  Domain  Imf^ementation  Activity  are  to: 

•  Create  a  set  of  Adaptable  Components  and  Generation  Procedures  as  specified  in  the  Product 
Design 

•  Create  a  standardized  Application  Engineering  |vocess  as  specified  in  the  Process  Requirements 

1.2  Required  Information 

The  Domain  Implementation  Activity  requires  the  following  information: 

•  Domain  Specification 

•  Legate  Products 

13  Required  Knowledge  AND  Experience 

The  Domain  Implementation  Activity  requires  domain  and  software  knowledge  and  experience  in: 

•  Ibchnolt^es  for  creating,  adapting,  and  composing  Adaptable  Components  into  systems  and 
the  verification  of  sudi  Adaptable  Components 

•  Documenting  and  providing  automated  support  for  Application  ^igineering  processes 

•  How  ^tems  in  the  domain  are  built  and  sufficient  expertise  to  create  and  document  the 
software  for  these  ^tems 

2.  PRODUCT  DESCRIPTION 

Name  Domain  Implementation 


Lev-117 


Purpose 


Contmt 


Vilification 

Criteria 


A  Domain  Implementation  contains  sets  of  Adafrtable  Components  and 
associated  production  procedures  that  you  can  use  to  create  standardized 
work  products  for  members  of  a  product  family.  The  Domain  Implementation 
also  consists  of  the  procedures,  documentation,  and,  optionally,  automation 
that  define  a  standard  Application  Ei^neering  process. 

A  Domain  Implementation  consists  of  two  components: 

•  Product  Implementation.  A  Product  Implonentatkai  contains  an 
adaptable  implementation  of  a  product  family  (see  Secticn  DE3.1). 

•  Process  Support.  An  application  engineering  infrastructure  that 
supports  the  practice  of  Application  Engineering  by  defining  the  pro¬ 
cedures  and  standards  by  which  application  engineers  develop 
applications  (see  Section  DE.3.2). 

The  Domain  Implementation  supports  the  product  family  identified  in  the 
Domain  Specification. 


3.  PROCESS  DESCRIPTION 

The  Domain  Implementation  Activity  consists  of  the  two  steps  shown  in  Figure  DE.3-1. 


. I . 

to 

Project  Support  and  Donuan  VerificaUon 


Figure  DE.3-1.  Domain  Imi^emenUtion  Process 


3.1  Procedure 

Follow  these  steps  for  the  Domain  Implementation  Activity. 

Step:  Product  Implementation  Activity 
Action  Implement  a  product  fomily. 

/lyutf  •  Domain  Specification 

•  Legacy  Products 

Resitit  Product  Implementation 

Heuristics  •  Derive  the  Product  Implementation  of  a  product  femily  from  apjx'oiniate 

Legacy  Products. 

•  Describe  a  mechanical  procedure  Ity  which  application  engineers  can 
select,  adapt,  and  compose  a  deliverable  application  work  prcxluct. 

Step:  Process  Support  Development  Activity 

Action  Create  an  application  en^eering  infrastructure  to  support  the  standardized 

process  by  wUch  application  engineers  develop  applications. 

Input  •  Product  Implementation 

•  Domain  Specification:  Pr(x;ess  Requirements 

Result  Process  Support 

Heuristics  •  Dcxnment  the  prcx%dures  and  standards  that  application  engineers  follow 

to  develop  applications. 

•  Optionally  provide  automated  mechanisms  which  support  the  effective 
and  correct  performance  of  the  Application  Engineering  process. 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contingauy  The  Domain  Specification  is  incomplete,  ambiguous,  or  inconsistent 

Source  Domain  Analysis  Activity 

Response  Desoibe  how  the  Domain  Specification  is  inadequate  and  suggest  how  it  may 

be  modified.  Proceed  with  Domain  Implementation  as  far  as  possible  with  the 
current  Domain  Spedfication. 

Contingency  Unforeseen  opportunities  arise  that  cannot  be  exploited  given  the  current 

Domain  Specification,  e.g.,  a  situation  u^ere  substantial  software  is  made 
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available  for  use  in  the  Domain  Imi^mnentatkm  diat  was  not  availatde  irihoi 
the  Domain  Specification  was  con^deted. 

Source  Domain  Anafysis  Activity 

Respotise  Document  the  opportunities  and  the  required  dianges  to  the  Domain 

Specification. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Domain  Implementation  is  incorrect,  inconsistent,  or  inoomidete. 

Source  Domain  Verification  Activity 

Respond  Request  clarification  of  the  intent  of  the  Domain  Specification,  if  necessary. 

Modify  the  Domain  Implementation  to  satisfy  the  Domain  Specification. 

Contingency  The  support  for  the  Application  Engineering  process  is  inefficient. 

Source  Project  Support  Activity 

Response  Revise  the  Domain  Implementation  based  on  Application  Engineering 

experience. 
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DE  PRODUCT  IMPLEMENTATION  ACnVITY 


1.  GETTING  STARTED 

The  Product  Implementatioii  Activity  is  the  activity  of  the  Domain  Imidementation  Activity  for 
creating  a  Product  Implementation.  A  Product  Implementation  is  an  imjdementation  a  jn-oduct  fami¬ 
ly.  A  conventional  implementation  is  an  application  and  associated  work  products  that  solve  a  ^)edfic 
problem.  Similarly,  a  Product  Implementation  is  an  imi^ementation  that  is  adaptable  to  decisions 
supported  by  the  fX'oduct  family’s  Decision  Model  in  order  to  solve  any  of  a  family  of  {M-oblems.  A 
Product  Implementation  consists  of  Adaptable  Components  (e.g.,  code,  documentation,  and  suf^rt 
for  verificationA^idation)  and  procedures,  as  needed,  for  selecting,  adiqstiqg,  and  cmnposing  these 
components.  The  Adaptable  Components  and  procedures  are  used  to  aeate  deliverable  ap^icadon  en¬ 
gineering  work  products  in  accordance  with  an  Api^cation  Model  that  describes  the  product. 

1.1  Objectives 

The  objective  of  the  Product  Implementation  Activity  is  to  implement  the  Product  Design.  This 
implementation  is  used  hy  application  engineers  to  generate  required  work  products  for  systems  in 
the  domain. 

1.2  Required  iNFORMAnoN 

The  Product  Implementation  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Design 

•  Decision  Model 

•  Legacy  Products 

U  Required  Knowledge  AND  Experience 

The  Product  Implementation  Activity  requires  domain  and  software  knowledge  and  e3q)erience  in: 

•  The  design  method  used  in  spedfying  the  Product  Design 

•  Existing  tystems  in  the  domain,  inducting  how  th^  are  designed,  implemented,  and  verified, 
and  what  are  their  components  and  architectures 
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•  Ikgetboigiiage  and  platform  c^Mbilities 

•  Thft  tnr  ariardng  and  compnmng  cfifnpnnentK  intn  wnrlc  pmrfiirtK  rtiat  malm  iip 

integrated  product 


2.  PRODUCT  DESCRlPnON 


Name 

Purpose 


Coutem 


Ver^ica^n 

CrUerim 


Product  Implementation 

A  Product  Imidementation  is  an  adaptable  imj^ementaticm  of  a  product 
family.  An  ap(^cation  engineer  must  be  aUe  to  (forive  numbers  of  a  ]vodua 
family  by  adapting  the  Product  Imidementadon  mecfaanicalfy  based  on  the 
product  famil/s  decisions  in  an  .^^dicatimi  Model. 

A  Product  Implementation  consists  of  the  following  parts: 

•  Adaptdbie  Components.  An  implementation  of  the  product  family's 
Component  Design.  Adaptable  Components  indude  software,  docu¬ 
mentation,  and  verificationA^dation  components  that  are  adapted 
based  on  the  product  family's  Decision  Model  (see  Section  DEJ.1.1). 
Adaptable  Components  may  be  derived  from  L^acy  Product  Collec¬ 
tively,  these  Adaptable  Components  form  all  of  the  necessary  compo¬ 
nents  for  constructing,  documenting,  verifyingA^dating,  and 
delivering  a  system. 

•  Generathn  Procedure.  An  implementation  of  a  Generation  Design  for 
selecting,  adapting,  and  composing  Adaptable  Components  into  deliv¬ 
erable  work  products  that  satisfy  an  A^lication  Model  (see  Section 
DE.3.1.2). 

There  is  a  Generation  Procedure  per  product  family.  The  Generation 
Procedure  unifies  a  set  of  separate  work  product  specific  Generation 
Procedures.  Eadiwork-produa-spedfic  Generation  Procedureoorre- 
sponds  to  a  particular  set  of  Adaptable  Components  in  a  Product 
Im[dementation. 

The  Product  Implementation  correctly  constructs  odsting  or  envisioned 
^tems  from  the  domain. 


3.  PROCESS  DESCRIPTION 

The  Product  Implementation  Activity  consists  of  the  two  steps  shown  in  Figure  DR3.1-1. 


3.1  Procedure 

Follow  these  steps  for  the  Product  Implementation  Activify. 
Step:  Component  Implementation  Activity 


DE3*1«  Product 


1 


to 

Process  Support  Devtlt^maO, 


ondDomain  Vei^icaSon 


Rgure  DEJ.M.  Roduct  ImpleiiienUitioo  Roceai 

Action  Create  Adaptable  Components  for  the  product  famify. 

•  Product  Requirement 

•  Product  Design 

•  Legacy  Products 

Result  Adaptable  Components 
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Derive  Adaptable  Components  from  Legacy  Products. 


•  Ensure  that  Ac  Adapud)le  Component  satisfies  and  is  onnAtgnt  with 
relevant  a^)ects  of  die  Product  De^  and  ftothict  Reqidranads. 

Step:  Generation  Implementation  Activity 

Action  Automate  or  document  a  mechanical  procedure  by  v^ch  application 

engineers  can  derive  deliverable  apfdication  work  products  consistent  with  an 
Application  Model. 

b^ut  •  Generation  Design 

•  Decision  Model 

•  Product  Design:  Product  Ardiitecture 

Resub  Generation  Procedure 

Hamstics  Ensure  that  the  Generation  Procedure  satisfies  and  is  consistent  with  relevant 

aspects  of  the  Generation  Design. 

Risk  Management 

JKsk  The  Product  Implementation  will  be  inconsistent  with  Product  Requirements. 

Implication  Application  work  products  will  be  generated  that  do  not  satisfy  the  Product 

Requirements. 

MiRgaRon  When  uncertainties  arise,  review  the  Domain  Specification  with  domain 

analysts  to  darify  their  intent  Review  the  Domain  Imi^ementation  with  other 
operienced  engineers  to  identify  omissions  and  inoonsistendes.  Derive  test 
work  products  based  on  knowledge  of  existing  or  antidpated  ^tems  for 
review  with  experienced  engineers. 

4.  D^RACnONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contit^aicy  The  Domain  Spedfication  is  incomplete,  ambiguous,  or  inconsistent 

Source  Domain  Spedfication  Activify 

Response  Desoibe  how  the  Domain  Spedfication  is  inadequate,  and  suggest  how  it  may 

be  modified.  Proceed  with  Product  Implementation  as  fin  as  possible  with  the 
current  Domain  Spedfication. 

Unforeseen  opportunities  arise  that  cannot  be  oqdoited  given  the  current 
Domain  Spedfication,  e.g.,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Domain  Imidementation  that  was  not  available  when 
the  Domain  Spedfication  was  completed. 


Confyigeney 
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SoHivt  Domain  Specification  Activity 

JBstyonsr  Document  the  0|^x>rtunities  and  the  required  dianges  to  die  Domain 

Specification. 

FBsdback  From  Product  Ck>KSUMnts 

Contingmey  The  Product  Im|dementati(Mi  does  not  satisty  the  Domain  l^)ecification. 

Source  Domain  Verification  Activity 

Resptmse  Request  clarification  of  the  intent  of  the  Dmnain  Spedtoukm  if  necessary. 

Mo^  the  Product  Imi^ementation  to  satisty  the  Domain  ^redfication. 
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This  pagi  jntmtumdfy  blank. 


DE  COMPONENT  IMPLEMENTATION 

ACnVITY 


1.  GETTING  STARTED 

Component  Implementation  is  an  activity  of  the  Prodtict  Imfriementation  Activity  for  creating  an 
Adai^able  Component.  A  component  is  any  work  i»roduct  fragment  (e.g.,  software,  documentation, 
or  verification/validation  artifact)  fx-oduced  during  the  Application  Engineering  process.  An  apfdica- 
timi  engineering  work  fx-oduct  consists  of  a  set  of  components.  An  AdaptaUe  Component  is  a  repre¬ 
sentation  of  a  family  of  components  that  satisfies  a  Component  Design  (i.e.,  is  adaptable  to  specified 
variations).  The  variability  of  an  Adaptable  Component  enables  application  engineers  to  extract 
components  to  be  used  in  creating  work  products  for  members  of  a  product  family. 

1.1  Objectives 

The  objective  of  the  Component  Implementation  Activity  is  to  imi^ement  an  Adaptable  Component 
that  satisfies  a  Component  Design,  consistent  with  relevant  aspects  of  the  Product  Requirements  and 
Product  Architecture. 

1.2  REQinRED  Information 

The  Component  Implementation  Activity  requires  the  following  information: 

•  Product  Requirements 

•  Product  Architecture 

•  Component  Design 

•  Legatty  Products 

13  Required  Knowledge  AND  Experience 

The  Component  Implementation  Activity  requires  domain  and  software  knowledge  and  experience 
in: 

•  Applicable  standards  and  tedmiques  for  design,  imidementation,  and  verification  of  software 
components 

•  How  to  design,  implement,  and  verify  components  of  a  work  product  family  given  a 
specification  for  the  family 

•  The  design  and  implementation  of  existing  tystems  in  the  domain 
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2.  PRODUCT  DESCRlPnON 


Name 

Purpose 

CosUaU 


Formal 

Structure 


Adaptable  Component 

An  Adaptable  Compcment  is  a  ocMnponent  (e^.,  of  s(^hvare,  documeiutation, 
verificationA^dati<Hi  support)  that  is  adaptaUe  with  respect  to  variations 
specified  in  the  Comixment  Design. 

An  Adaptable  Component  is  an  imf^ementadmi  (tf  a  family  of  ccmqxmmts. 
This  fai^  is  defined  by  a  Component  Design,  with  support  by  porti<Mis  of  the 
Product  l^uirements  ami  Product  Architecture.  The  Compmient  Dedgn 
characterizes  an  Adaptable  Component  by  specifying  the  pennissiUe 
adaptations  of  the  component,  along  with  the  desired  characteristics  of  its 
implementation. 

An  Adaptable  Component  is  uniquely  named  and  consists  of  two  parts:  an 
adaptability  interface  and  a  body. 

A  component  family  is  characterized  by  a  set  of  common  capabilities  ami 
variations  in  those  capabilities.  The  adaptabilify  interface  is  a  specification  of 
a  set  of  adaptation  parameters  that  provide  for  the  characterization  and 
extraction  of  a  particdar  instance  of  a  component  family. 

The  body  is  the  sum  of  the  potential  implementations  of  all  of  the  components 
in  the  family.  The  term  "potential”  is  used  because  the  parameters  are 
suffident  to  select  ai^  component  family  instance  uniquely,  but  the  particular 
implementation  either  may  not  be  available  or  may  be  extracted  from  a 
representation  of  the  family  or  relevant  subfamity.  This  varies  with  the 
mechanism  used  for  implementing  adaptability  in  the  Adaptable  Ccxnpcment 
Three  common  medianisms  for  implementing  an  Adaptable  Component  are: 

•  Pkyskal  Squmtion.  Represent  members  of  the  component  set  as 
physically  distinct  entities  (e.g.,  in  separate  files  on  a  computer). 

•  Target-La/^utqe  Mechanisms.  Use  the  language-specific  facilities  to 

represent  different  component  set  members.  generics,  C+  +  tem¬ 

plates,  Interleaf  efifectivify  control,  and  WordPerfect  macro  features 
are  examples  of  target-language  medianisms  for  rejn'esenting  an 
Adaptable  Component. 

•  MdiqpmgraiifiifMg.  Superimpose  a  language  for  handling  variations  on 
top  of  the  language  in  which  all  members  of  the  component  set  are 
extH-essed. 

These  may  be  used  separately  or  in  combination  to  implement  a  particular  set 
of  components. 

The  Booch  Ada  stack  packages  (Booefa  1987)  are  an  example  of  an  Adaptable 
Component.  There  is  a  unifying  concept  of  ^^t  a  stadc  is  and  how  it  works. 
Different  stack  components  are  extracted  based  on  dedsions  such  as: 
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•  Type.  The  type  of  data  that  can  be  put  into  the  stack. 

•  Iteration.  Whether  an  indexing  mechanism  should  be  available  for 
moving  forward  and  badcward  through  the  stack  in  addition  to  simidy 
pushing  elements  onto  and  popfdng  elements  ofif  of  the  t(^  of  the 
stack. 

•  Garbage  CMection.  Whether  the  stadc  slmuld  manage  unused  stadc 
space  dynamically  for  later  use. 

•  Bounding.  Whether  the  stack  should  be  bounded  in  length. 

The  Booch  packages  use  |diysical  separation  to  implement  26  different  ^pes 
of  stacks.  TUs  physical  separation  approach  has  the  advantage  of  being  simple. 
If  a  family  has  10  instances,  there  are  10  implementations  and  eadi  can  be 
written  and  verified  independently.  Physical  separation  does  not  take 
advantage  of  similarities  among  the  instances,  however,  nor  does  it  make 
explicit  how  variabilities  determine  the  content  of  each  instance. 

Ada  provides  generic  pedcages  as  a  standard  facility  diat  you  can  use  to  inqdement 
a  00^  Adaptable  Ccai^xm^t  whose  instances  differ  onty  in  the  v^ues  of 
well-d^ed  {daceholders  diat  can  be  substituted  at  compile  time.  The  ‘‘type’* 
variability  of  stack  packages  mtty  be  rqxesoited  a  gen^  package.  The 
fdaceholdeis  are  parameters  defi^  in  the  adaptability  interfiice  of  ^  AdaptaUe 
CcHi^nent.  This  approach  has  die  advantage  of  rqxesentii^g  variabilities  for  the 
component  family  mcare  ocanpactty  and  uniformty;  however,  onty  a  simple  form  of 
parameter  substitution  is  siqipcxted. 

A  metaprpgramming  t^oach  (Canqibdl  1989)  uses  a  prqxocessiqg  mechanism 
to  extract  a  concrete  component  frcxn  an  AdapOiAe  CompcsaenL  This  approach 
embeds  taiget  text  fiagments  ol  a  wc^  product  {eg,  code,  documemation, 
vaificationtyalidatkm  support)  witii  a  supoinqxised  metaprogramming  notatkm. 
The  metaprqgramming  notation  specifies  how  the  target  fiagmoits  are  to  be 
ocnnbined  and  acUfited,  based  cm  die  parameters  in  the  adaptability  intofooe  die 
Ads^itable  Component  'typical  metaprogrammii^  adaplaticxis  indude: 

•  Substitution  of  parameter  values 

•  Conditional  inclusion  of  tot  firagments 

•  Repetition  of  text  fragments 

•  Definition  and  in-line  instantiation  of  parameterized  fragments 

This  approach  provides  greater  flexibility  in  representing  a  component  family 
compacdy  but  results  in  more  complmc  des^iptions.  Since  many  implementa¬ 
tions  may  be  derived  from  a  single  description,  domain  engineers  must  both 
manually  inspect  that  desaiption  and  ^ract  and  verify  representative 
instances.  Exmple  DE.3.1.1-1  illustrates  a  small  fragment  of  a  Component 
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nuuu.Q 


Impleineiiuuion  for  tbe  TlX^  <k)aiaiiL  This  exaoqile  oxitaiiis  a  portkm  of  tile 
im^moitatioa  for  the  Ad^itaUe  Con^xMient  q)edfied  in  Enaqsie 
DE^4^1. 


Component  In^iiemeatetkn  - 

qfpeniodeie(  — en  enumerated  type  deieribing  the  dtffaent  traffic  lijjtfechetliaet 

<rorali  a  in  •ciMdale> 

<smaiae>, 

<eBdfbr> 

unknomn 

); 


functka  detennine_sd)edule_tnniitioa  return  mode  it 
clock_time :  c; 
be^ 

c get_dock_time; 

<forall  a  in  adiediik> 

if  c>s  <t.atart> and c <s  <i^d> then 
return  <ijuuiic>; 

elsif 

<cndfor> 

•««« 

endif; 

end  detennine_adiedule_trantition; 


Examjde  DEJ.1.1*!.  Fragment  of  TLCCompoDeotlniplenientatioo 


HaifkatUm 

Criteria 


The  Adaptable  Components  implement  their  specifications  as  defined  in 
the  Product  Architecture  and  Component  Designs. 

The  Adaptable  Components  produce  the  correct  variations  in  concrete 
components. 

Behaviors  or  constraints  imposed  by  Product  Requirements  or  Product 
Architecture  on  the  Adaptable  Component  are  all  supported. 


3.  PROCESS  DESCRIPTION 

The  Component  Implementation  process  consists  of  all  activities  necessary  for  imi^ementing  an 
Adaptable  Component  to  its  Component  Design  spedfications,  consistent  with  relevant  parts  of  the 
Product  Ardiitecture  and  Product  Requirements.  This  involves  the  design,  imidementation,  and  veri¬ 
fication  of  the  family  of  software,  documentation,  or  test-suf^rt  components.  It  may  involve  the 
reengineering  of  existing  components  of  work  products  firom  previously  built  ^tems.  The 
Component  Imjdementation  Activity  consists  of  the  three  steps  shown  in  Figure  DE  J.1.1-1. 


3.1  Procedure 

Follow  these  steps  for  the  Component  Implementation  Activity. 


Lo^iao 


DEJ.1.1. 


It  ImtitetBitfatiM 


I^gure  DEJ.1.1-1.  Component  InqdemeatatioD  ftooess 


Step:  Design  the  Component’s  Internal  Stmctnre 


Action 


Input 


Result 


Heuristics 


Create  an  internal  design  of  the  structure  and  elements  of  the  required 

Adaptable  Component 

•  Component  Design 

•  Product  Architecture 

•  Legacy  Products 

•  Adaptable  Component:  Internal  design 

•  Candidate  Components 

•  The  Adaptable  Components  internal  design  must  satisfy  its  Component 
Design  specification.  The  structures  of  the  Product  Ardtitecture  may  im¬ 
pose  additional  requirements  on  the  internal  structure  (e.g.,  for  concur¬ 
rency  or  level  of  performance)  or  define  constraints  on  how  other 
components  are  us^  in  the  imf^ementation. 
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•  Envision  how  to  implement  required  members  (rf  the  oomponenfs  wwlc 
product  family.  Create  structures,  according  to  the  design  method  used, 
that  characterize  the  required  im^dementation.  Parameterize  eadi 
structure,  if  appropriate,  with  adaptability  parameters  that  vary  the  struc¬ 
ture,  as  required,  for  different  members  of  the  component  family. 
Consider  the  required  operations  of  the  members. 

•  Determine  whether  a  suitable  component  that  approximates  one  of  these 
desired  instances  is  available  from  Legacy  Products.  Identify  and  evaluate 
the  quality  of  each  such  component  and  designate  it  as  a  Candidate  Com¬ 
ponent  for  further  use.  Determine  ufrich  Adaptable  Component  variations 
are  imfdidtly  addressed  by  this  selected  Can^date  Component. 

•  Consider  whether  other  Adaptable  Components  in  the  Product 
Architecture  can  be  used  to  implement  all  or  part  of  this  component  fami¬ 
ly.  Components  that  have  complex  functionality  may  be  im|dementable  as 
a  composition  of  instances  of  other,  more  primitive  components. 

•  Consider  starting  with  the  internal  designs  of  identified  Candidate 
Components.  Portions  of  several  candidate  components  may  be  used 
collectively  to  implement  the  Adaptable  Component.  These  components 
may  implement  different  variations  that  will  be  required  for  the  family. 
Characterize  which  instance  of  the  family  corresponds  to  each  component 
(i.e.,  by  its  parameter  values).  Consider  whether  each  design  is  sufSciently 
well-engineered  and  representative  of  the  family,  or  at  the  least  of  a 
subfamily,  to  provide  substantial  leverage  in  being  refined  to  represent 
other  variations  and  the  family  as  a  whole.  Consider  that  they  may 
represent  different  subfamilies  Aat  should  be  structured  differently.  See 
if  their  designs  can  be  unified  using  variations.  Be  sure  you  can  still  derive 
each  of  the  components  with  an  acceptable  structure. 

•  Use  adaptation  mechanisms  (e.g.,  target-language  mechanisms, 
metaprogranuning)  alrea<fy  present  in  the  existing  work  products. 

Step:  Implement  the  Component 

Action  Elaborate  the  internal  design  to  implement  the  Adaptable  Component. 

Input  •  Adaptable  Component:  Internal  design 

•  Component  Design 

•  Product  Architecture 

•  Candidate  Components 

•  Legacy  Products 


Result 


Adaptable  Component 


DE3.1.1.  Compoaeat  Imptemeimtioa  AcMty 


Heuristics  •  Fill  in  the  internal  structure  with  the  details  of  the  implementation.  Keep 

in  mind  how  the  adaptabilities  affect  the  content  of  the  parts  of  the 
structure. 

•  If  suitable  Candidate  Components  were  used  in  seating  the  internal 
design,  the  n  the  implementations  of  those  components  can  be  useful  as  the 
starting  point  in  implementing  the  Adaptable  Component. 

•  If  another  Adaptable  Components  is  to  be  used  in  implementing  this 
Component,  determine  how  the  adaptability  parameters  of  this  Compo¬ 
nent  can  be  mapped  into  the  parameters  of  that  Component  so  that  its 
correct  instance  is  derived  for  a  particular  instance  of  this  family. 

•  Parts  of  the  Adaptable  Component  might  have  to  be  engineered  from 
scratch  if  all  elements  of  the  Adaptable  Component’s  implementation  can¬ 
not  be  obtained  from  existing  Cwdidate  Components  or  other  Adaptable 
Components.  These  areas  should  be  given  much  greater  thought  to  ensure 
that  you  produce  the  correct  content. 

•  Consider  reengineering  existing  application  engineering  work  products 
(e.g..  Legacy  Products)  to  increase  their  reusability.  For  example,  you 
might  want  to  replace  arbitrary  limits  on  data  structure  size  with  generic 
parameters.  You  should  consider  this  if  it  will  relax  or  remove  constraints 
in  your  Decision  Model.  You  should  take  into  account  any  documentation 
or  coding  standards  for  the  targeted  project  when  you  reengineer  existing 
work  products. 

Step:  Verify  the  Component 

Action  Verify  that  the  Adaptable  Component  satisfies  all  relevant  specifications. 

Input  •  Adaptable  Component 

•  Component  Design 

•  Product  Architecture 

•  Product  Requirements 

•  Candidate  Components 

Besitit  Verified  Adaptable  Component 

Heuristics  •  Perform  rigorous  inspection  of  the  Adaptable  Component  by  other 

experienced  engineers.  The  Component  Design,  as  well  as  relevant  parts 
of  the  Product  Requirements  and  Product  Architecture,  should  be  verified 
as  being  satisfied. 

•  Derive  representative  instances  of  the  Adaptable  Component  and  test 
those  instances  in  a  conventional  fashion  to  see  if  they  operate  correctly. 
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One  part  of  this  activity  is  the  creation  of  test-case  scenarros  that  can  be 
used  in  regression  testing  of  the  Adaptable  Component  when  it  is  modified 
in  the  future.  These  scenarios  may  be  made  adaiMtd)le  to  the  same  parame¬ 
ters  as  the  Adaptable  Component  itself  so  that  a  scenario  can  be  derived 
for  a  particular  test  instance. 

•  Rederive  the  Candidate  Components  that  influenced  the  implementation 
of  the  Adaptable  Component.  The  original  and  derived  instances  can  then 
be  compared  to  see  if  and  how  they  differ  and  whether  an  equivalent  result 
can  be  produced. 

•  Use  of  a  Candidate  Component  may  have  been  based  on  assurances  that 
the  component  received  with  respect  to  certain  desired  properties  sudi  as 
correctness,  reliability,  certification,  and  trust  (in  the  security  sense). 
Note,  however,  that  modification  of  the  component  can  invalidate  some 
of  these  assurances  (i.e.,  certification  and  trust).  It  is  important  to  verify 
that  the  desired  properties  are  retained  when  the  component  is  extracted 
from  the  resulting  ^aptable  Component. 


3.2  Risk  Management 


Risk 


bnfiicadon 

Mtigation 


Certain  combinations  of  adaptaNliiy  are  not  fiilfy  supplied  in  the  Adaptable 
Component 

Work  products  for  some  systems  will  not  be  derivable  using  the  Component. 

In  verifying  the  Adaptable  Component,  use  bounds-coverage  techniques  to 
identify  a  variety  of  adaptability  combinations  in  deriving  test  instances. 


^sk  The  effort  required  to  implement  all  specified  adaptabilities  for  an  Adaptable 

Component  is  not  viable  compared  to  that  required  to  develop  concrete 
components  which  support  a  single  system  development  effort. 


ImpUcation 


Only  a  subfamily  of  the  Adaptable  Component  will  be  available  for  production 
of  systems  in  the  domain. 


Mtigation 


Risk 


bnpikadon 


Implement  the  variations  required  for  the  current  systems  under 
development.  The  development  of  these  variations  may  require  less  effort 
than  developing  all  possible  variations  and  can  be  refined  as  additional  needs 
arise.  The  Adaptable  Component  can  be  evolved  to  a  completed  state  over 
several  development  iterations  of  a  system  or  systems. 

Determining  the  value  of  casting  components  as  a  basis  for  the  Adaptable 
Component  will  require  toomudi  effort  (e.g.,  too  many  components  to  search 
thro^,  too  labor  intensive  to  look  through  complicated  components,  too 
difficult  to  determine  whether  a  component  is  correctly  implemented). 

Effort  to  evaluate  and  reengineer  existing  components  «cceeds  the  effort  to 
create  the  Adaptable  Component  from  scratch. 
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DE3.1.1.  Component  Imptcmenuiioo  Aetwiiy 


MitHgation 


Risk 


ImpUeation 


Mitigation 


If  there  are  too  many  existing  components  to  search  through  to  find  a  good 
baseline  component,  limit  the  amount  of  effort  dedicated  to  the  search,  and 
use  the  best  approximation  that  results  from  the  limited  search. 

If  looking  through  complicated  components  is  too  labor-intensive,  reduce  the 
number  of  components  that  will  be  reviewed.  If  the  component  is  overly 
complicated,  relying  on  higher-level  documentation  (i.e.,  requirements, 
high-level  design,  or  testing  documentation)  of  the  component  as  an  indicator 
of  its  worth  may  be  beneficial.  Reviewing  documentation  on  the  existing 
component  is  likely  to  take  less  effort  than  reviewing  code. 

If  determining  the  correcmess  of  the  component  is  difficult,  then  determining 
correctness  from  previous  test  documentation  may  be  sufficient  Reliance  on 
existing  components  may  be  ^eater  if  engineers  are  available  who  developed, 
or  at  least  used,  the  existing  components. 

Modifying  the  baseline  component  may  invalidate  assurances  of  qualify  that 
the  component  possessed  (e.g.,  certification). 

Modifying  a  certified  component  will  require  that  the  resulting  Adaptable 
Component  must  pass,  once  again,  the  tests  required  for  assurance  of  given 
properties. 

•  Concentrate  effort  on  areas  of  particular  concern.  If  the  given  properties 
are  less  important  for  the  component  family  as  a  whole,  treat  that  particu¬ 
lar  member  as  a  special  case  (i.e.,  a  component  subfamily  in  its  own  right). 
That  is,  if  a  component  family  contains  several  members,  only  one  ofwhich 
is  certified,  define  two  Adaptable  Components,  one  whose  component 
family  contains  the  certified  member  and  another  which  contains  all  the 
uncertified  members. 

•  Ty  to  retain  the  essential  nature  of  the  baseline  component  in  the 
Adaptable  Component  so  that  proving  assurance  of  given  properties  is  not 
an  expensive  process. 


4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 

Contingency  The  Component  Design  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Component  Design  Activify 

Response  Desaibe  how  the  Component  Design  is  inadequate,  and  suggest  how  it  may 

be  modified.  Proceed  with  Component  Implementation  as  far  as  possible  with 
the  current  Component  Design. 

4.2  Feedback  From  Product  Consumers 

Contingency  The  Component  Implementation  does  not  satisfy  the  Component  Design. 
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Sourt* 


Domain  Verification  Activity 


Eespmst 


Request  clarification  of  the  intent  of  the  Conqxment  Des^  if  necessary. 
Modify  the  Component  Implementation  to  sati^  the  Cmnponent  Design. 


DE3.1.2.  GENERATION  IMPIJMENTATION 

ACnVITY 


1.  GETTING  STARTED 

Generation  Implementation  is  an  activity  of  the  Product  Implementation  Activity  ftv  aeating  a 
Generation  Pro<%dure.  A  Generation  Procure  is  a  {vedse  description  of  how  to  derive  deliverable 
ai^lication  engineering  work  products  consistent  with  the  dedsions  in  an  Api^cation  Model  for  a 
product  family.  A  Generation  Procedure  may  be  automated  or  nuiy  take  the  form  of  a  predie 
description  that  application  engineers  can  medhanically  follow  to  create  work  {xroducts. 

1.1  OnjEcnvES 

The  objective  of  the  Generation  Implementation  Activity  is  to  create  a  Generation  Prottdure  ai 
spedfied  by  a  Generation  Design. 

1.2  Required  Information 

The  Generation  Implementation  Activity  requires  the  following  information: 

•  Generation  Design 

•  Product  Architecture 

•  Dedsion  Model 

•  Component  Designs 

IJ  Required  Knowledge  AND  Experience 

The  Generation  Implementation  Activity  requires  knoMedge  and  oqwrience  in: 

•  The  notation  used  in  spedfying  the  Generation  Design 

•  The  technolt^es  for  adapting  and  composing  components  into  work  i»:oducts 

2.  PRODUCT  DESCRIPTION 

Name  Generation  Procedure 


Levels? 


Purpeae 


This  is  a  procedure  that  an  i4)plication  ei^uieer  uses  to  aeate  delimable 
api^cation  engineering  work  products  for  a  member  of  a  product  family  using 
Adaptable  Components.  This  procedure  is  either  imfdemented  as  a  product 
generator  or  documented  as  a  manual  procedure. 

Contoa  The  Generation  Procedure  is  a  procedural  description  for  producing  an 

application  engineering  work  product  that  satisfies  the  maj^ungs  (tf  a 
Generation  Design.  The  Generation  Procedure  describes  how  to  select 
appropriate  Adaptable  Components,  how  to  apply  decisions  fi’om  an 
/plication  Model  to  adapt  them,  and  how  to  compose  them  to  aeate  the 
work  produa  in  final  form. 

The  form  of  the  Generation  Procedure  depends  on  i^ether  the  procedure  is 
automated  or  manual.  The  Generation  Procedure  is  either  implemented  as  an 
automated  produa  generator  or  documented  as  a  manual  procedure  to  be 
followed  by  application  engineers.  If  the  manual  form  is  chosen,  then  the 
Generation  Procedure  form  is  likely  to  resemble  the  form  of  a  Generation 
Design.  If  the  Generation  Procedure  is  implemented  in  the  form  of  a  {H'odua 
generator,  however,  it  will  be  a  conventional  software  program. 

Var^kation  •  The  Generation  Procedure  for  a  produa  family  can  be  used  to  produce  ap- 

Criteria  plication  engineering  work  products  that  exhibit  the  internal  organization 

specified  in  the  Produa  Architeaure. 

•  TheGenerationProcedurefiaaproduafiunifycanbeusedtoproduce^jplica- 
tion  oi^eaing  work  products  that  satisfy  the  Produa  Kequiremenls. 

•  If  a  manual  form  is  used,  the  Generation  Procedure  for  a  produa  family 
clearly  describes  how  deliverable  application  engineering  work  products 
are  construaed  from  Adaptable  Components  based  upon  decisions 
contained  in  an  Application  Model. 

3.  PROCESS  DESCRIPTION 

The  Generation  Implementation  Activify  consists  of  the  two  steps  shown  in  Figure  DE.3.1.2-1. 

3.1  Procedure 

Perform  one  or  both  of  the  following  two  steps.  The  appropriate  action  depends  on  what  automation 
you  determine  to  have  a  significant  payoff  in  ^plication  Engineering. 

Step:  Document  the  Generation  Procedure 

Action  Document  some  or  all  of  the  Generation  Design. 

Input  •  Generation  Design 

•  Produa  Ardiitecture 

•  Decision  Model 

•  Component  Designs 


Farm  and 
Sttvetun 
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Rgure  DR3.1  Generatioo  ImptemenUtko  Roccw 

Resuit  Generation  Procedure 

Heuristics  •  The  Generation  Design  is  apredsedescriptionoftherequiredGeneration 

Procedure.  Document  the  procedure  in  a  form  that  is  us^le  by  api^ication 
engineers. 

•  Indude  a  desoiption  of  how  components  are  composed  to  form  a  work 
I»oduct  consistent  with  its  Product  Architecture. 

•  Indude  a  description  of  how  to  access  the  decisions  in  an  ^>idication 
Model  for  a  product  family.  The  Decision  Model  provides  the 
organization  of  Ae  decisions*  conceptual  sdiema. 

Step:  Automate  the  Generation  Procedure 

Action  Develop  automated  tools  that  implement  some  or  all  of  the  Generation 

Procedure  as  defined  in  the  Generation  Design. 

Input  •  Generation  Design 

•  Product  Architecture 


Dedsion  Model 
Component  Designs 
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Baub  Generation  Procedure 

Heuristics  •  If  the  Application  Modeling  Activity  in  ^^cation  Engineering  is 

supported  1^  automation,  then  the  Generation  ^ocedure  must  access  the 
Application  Model  specification.  If  the  activity  is  not  automated,  then 
there  must  be  an  automated  mechanism  for  (ffoviding  the  decisions  of  the 
Application  Model  as  input  to  the  Generation  Procedure.  The  Decision 
Model  provides  the  organization  of  the  decisions'  conceptual  schema. 

•  If  a  metaprogramming  tedmology,  such  as  described  in  the  Component 
Implementation  Activity  (see  Se^on  DE.3.1.1),  is  used  to  implement  the 
Adaptable  Components,  then  the  same  metaprogramming  technology  is 
used  to  instantiate  those  components.  Metaprogramming  technology  may 
also  be  useful  in  implementing  portions  of  the  Generation  Procedure 
itself. 

•  Creating  an  automated  Generation  Procedure  is  a  software  development 
task.  It  requires  the  design  of  the  required  program,  implementation  to 
that  design  in  a  programming  language,  testing  to  verify  that  the  resulting 
program  implements  the  Generation  Design  correctly,  and  documenta¬ 
tion  so  that  the  program  can  be  correctly  modified  as  the  Generation 
Design  changes. 

•  Ibols  such  as  the  UNIX  make  fadlify  may  be  useful  in  automating  the 
procedure  for  composing  adapted  components  into  deliverable  work 
products. 

3.2  Risk  Management 

None 

4.  INTERACTIONS  WITH  OTHER  ACTIVITIES 

4.1  Feedback  TO  Information  Sources 

Contingency  The  Generation  Design  is  incomplete,  ambiguous,  or  inconsistent. 

Source  Generation  Design  Activity 

Reqjonse  Describe  how  the  Generation  Design  is  inadequate,  and  suggest  how  it  may  be 

modified.  Proceed  with  Generation  Implementation  activity  as  far  as  possible 
with  the  current  Generation  Design. 

Contingency  Unforeseen  opportunities  arise  that  cannot  be  exploited  given  the  current 

Generation  Design,  e.g.,  a  situation  where  substantial  software  is  made 
available  for  use  in  the  Generation  Implementation  that  was  not  available 
when  the  Generation  Design  was  completed. 

Smarce  Generation  Design  Activity 
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Rtspomt 

E)ocument  the  cq)p(Btuiiities  and  the  required  chaises  to  the  Generatkm 
Des^. 

4J  Feedback  FKom 

Product  OmsDMEBs 

Contmtmty 

The  Generation  Procedure  does  ikh  satisfy  the  Generation  Design. 

Soyne 

Domain  Verification  Activity 

Response 

Request  clarification  of  the  intent  of  the  Generation  Deagn  if  necessary. 
Modify  the  Generation  Procedure  to  satisfy  the  Generatkm  Design. 

Cemtinteney 

A  manual  Generation  Procedure  is  difficult  to  use. 

Souete 

Project  Support  Activity 

Response 

Investigate  new  forms  for  conveying  the  Generatiim  Procedure  to  the 
af^lication  engineers. 

Condngetxy 

The  Generation  Procedure  cannot  be  used  in  its  current  fmin  in  the 
^iplication  Engineering  process. 

Source 

Process  Support  Develoinnent  Activify 

Response 

Revise  the  Generatimi  Procedure  (e.g.,  improve  automation  or  upgrade 
documentation)  so  that  it  can  be  effectively  used  by  application  engineers. 
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DE3.2.  PROCESS  SUPPORT  DEVELOPMENT 

ACTTVITY 


1.  GETTING  STARTED 

The  Process  Support  Development  Activity  is  the  activity  of  Domain  Implementation  for  creating  the 
Process  Support  component  of  Domain  Implementation.  Process  Support  is  the  infrastructure  that 
supports  the  practice  of  Application  Engineering  by  defining  the  procedures  and  standards  by  udiich 
ap^cation  engineers  develop  applications  (i.e.,  the  Ap^catioD  Engineering  process).  It  optionally 
provides  automated  mechanisms  \^ch  support  the  effective  and  correct  performance  of  the  ^}plica> 
tion  Engineering  process  and  associated  use  of  the  Product  Implementation  component  of  Etomain 
Implementation. 

1.1  Objectives 

The  objectives  of  the  Process  Support  Development  Activity  are  to: 

•  Document  polides  and  procedures  that  institute  a  standard  Application  Engineering  process 
and  that  guide  its  proper  performance 

•  Determine  the  appro{xiate  degree  of  automation  that  will  support  the  Apfdication 
Engineering  process  and  construct  the  automated  support 

IJl  Required  Information 

The  Process  Support  Development  Activity  requires  the  following  information: 

•  Process  Requirements 

•  Product  Implementation 

13  Required  Knowledge  AND  Experience 

The  Process  Support  Development  Activity  requires  domain  knowledge  and  experience  in: 

•  Documenting,  in  a  coherent  and  usable  form,  the  use  of  conventions,  polides,  and  procedures 

•  How  to  develop  and  communicate  process  standards  in  a  condse  and  usable  form 

•  Software  production  processes,  methods,  and  practices 
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•  Ibols  and  technologies  diat  can  support  an  ApplicatioaEi)gimerii^proc^(e.g.,ivodiidng 
code/documents/tests,  simulation^aodeling) 

•  Developing  user  documentation  and  training  courses  for  software  devel(^Mnent  processes 

This  activity  also  requires  the  following  additional  opertise  if  you  are  planning  to  automate  portions 

of  the  Application  Engineering  process: 

•  The  principles  and  use  of  appropriate  software  development  methods. 

•  Human-madiine  interface  factors  and  related  technology. 

•  Database  technologies  supportive  of  computer-aided  software  engineering. 

•  Host  platform  capabilities.  The  host  platform  is  the  hardware/software  environment  in  u^ch 
the  automated  portions  of  the  Apfdication  Engineering  process  execute. 

•  Ikrget  platform  capabilities.  The  target  i^atform  is  the  hardware/software  environment  in 
whidi  the  af^lication  produced  by  the  Api^cation  Engineering  process  executes. 

2.  PRODUCT  DESCRIPTION 

Name  Process  Support 

Purpose  Process  Support  is  a  description  and  explanation  of  the  policies  and 

procedures  by  which  application  engineers  produce  a  work  product  (the 
implication  Engineering  process)  and  automated  support  for  effident 
performance  of  the  ^iplication  Engineering  process. 

Content  Process  Support  consists  of  five  parts: 

•  Application  Et^ineerb^  Process  StamianL'ndsestebUshesihepolideseind 
procedures  that  govern  the  Application  Engineering  process  within 
the  framework  defined  by  the  Process  Requirements. 

•  Application  &^ineerit^  User's  Guide.  A  document  that  guides 
application  engineers  in  how  to  perform  the  Application  Engineering 
process  to  produce  a  product. 

•  ^plication  Et^jineering  Environment.  The  environment  consists  of  the 
auhmiated  medianisms  diat  siq^port  the  Apj^ication  Engineoing  process. 

•  Application  Engineering  Emdronment  Support  ManudLTba&i&eiK^Xtm 
administration  manual  desaibing  how  to  install  and  maintain  the 
Application  Engineenng  Environment  for  a  project.  It  provides  ap¬ 
propriate  information  on  any  vendor-supplied  software  technologies 
contained  in  the  environment. 

•  Appiicadon]^tgiitueritigTraitimgCourses.l}ai&TcaXcn^is}a&cdxott^ 
application  engineers  on  how  to  perform  the  Aj}plication  Engineering 
process  and  how  to  use  Application  Engineering  Process  Support. 
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Ikrifkatum  •  Members  of  the  product  family  can  be  produced  using  the  A{^cation 

Criteria  Engineering  Environment  by  following  the  User’s  Guide. 

•  Process  Support  prescribes  an  effective  and  efiSdent  Af^icadon 
Engineering  process. 

•  Process  Requirements  are  fully  satisfied  Process  Support 

•  Process  Support  provides  the  ability  to  spedfy  and  generated  the  entire 
product  family  suf^rted  by  Product  Implementadon. 

2.1  Appucahon  Engineering  Process  Standabd 

Purpose  The  Application  Ei^ineeru^  Process  Standard  gives  an  overview  of  the 

standards,  polides,  and  procedures  that  govern  how  application  engineers 
should  practice  application  engineering  satisfactorily. 

Content  The  Application  Engineering  Process  Standard  documents  the  essentials  of 

the  Application  Engineering  process  induding  what  has  to  be  done,  why,  and 
who  completes  the  work.  It  also  identifies  and  prescribes  standarck  for  fonn  and 
content  of  application  engineering  work  products. 

Form  and  The  form  and  structure  of  the  Application  Engineering  Process  Standard 

Structure  should  adhere  to  your  organization’s  current  standards  for  documenting 

polides  and  procedures. 

Verificadon  •  The  polides  and  procedures  documented  in  the  ^plication  Engineering 

Criteria  Process  Standard  are  consistent  with  the  Process  Requirements. 

•  The  polides  and  procedures  documented  in  the  Application  Engineering 
Process  Standard  do  not  conflict  with  other  applicable  organizational  or 
customer  standards. 

2.2  Appucation  Engineering  USER’S  Guide 

Purpose  The  Application  Engineering  User’s  Guide  provides  a  detailed  description  of 

how  application  engineers  should  perform  to  comply  with  the  ^}plication 
Engineering  Process  Standard.  This  guide  expresses  the  dedsion-making 
process  that  application  engineers  follow  for  a  domain. 

Content  The  ^plication  Engineering  User’s  Guide  instructs  application  engineers  on 

how  to  build  applications  that  have  particular  characteristics  and  explains  how 
to  create,  interpret,  and  evaluate  A^lication  Models  jn-operly.  This  guide 
also  designates  and  explains  the  effective  use  of  automated  me^anisms  that 
support  the  process. 

Form  and  The  User’s  Guide  should  conform  to  your  organization’s  standards  and 

Structure  guidelines  for  documentation. 
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Vuifiet^n  The  User’s  Guide  describes  how  to  build  an  application  product 

Criteria 

23  Appucation  Engineering  Environment 


Purpose 


Content 


Form  and 
Structure 


Verificatwn 

Criteria 


The  >^plication  Engineering  Environment  consists  of  all  automated 
mechanisms,  described  in  the  User’s  Guide,  that  suf^rt  aeating  and 
evaluating  Application  Models  and  generatu^  and  d^vering  equivalent 
application  pr^ucts.  The  Ai^lication  Engineering  Environment  automates 
the  mechanical  portions  of  the  process  for  inoreased  consistency  within  a 
product  and  less  opportunities  for  undetected  error  in  produdng  a  product. 

The  Application  Engineering  Environment  consists  of  both  tools  that  are  part 
of  the  host  operating  system  and  tools  developed  during  this  activity.  Ibge^er, 
they  support  the  Application  &igineering  process. 

•  The  tools  adhere  to  the  organization’s  standards  and  conventions  for  its 
software  development  environment. 

•  The  view  of  the  domain  provided  by  the  Application  Engineering 
Environment  must  fadlitate  the  tasks  application  engineers  undertake 
when  using  it.  The  Application  Engineering  User’s  Guide  describes  these 
tasks  in  detail. 

•  All  automated  tools  described  in  the  User’s  Guide  exist  and  behave  as  the 
User's  Guide  states.  All  Adaptable  Components  produced  during 
Component  Implementation  Activities  are  accessible. 

•  Automated  mechanisms  contain  no  residual  errors. 


2.4  Appucation  Engineering  Environment  Support  Manual 


Purptm 


Content 

Form  and 
Structure 

Ver^iaition 

Criteria 


The  Application  Engineering  Environment  Support  Manual  describes  how  to 
install  the  automated  mechanisms  of  the  implication  Engineering 
Environment. 

The  instructions  contained  in  this  manual  will  be  specific  to  your  organization. 

The  form  and  structure  of  the  support  manual  should  adhere  to  your 
organization’s  current  standards  for  such  work  products. 

Automated  mechanisms  can  be  installed  on  supported  platforms  without 
additional  unspecified  information  or  excessive  effort. 


2.5  Appucation  Engineering  Training  Courses 

Purpt^  These  courses  are  used  to  train  application  engineers  on  how  to  perform  the 

Application  Engineering  process  using  the  Process  Support. 

Content  The  content  is  determined  by  how  much  expertise  application  engineers  need 

in  your  organization  to  effectively  perform  Application  Engineering. 
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Frnnand  The  form  and  structure  of  the  training  courses  should  adhere  to  your 

Structun  organization’s  current  standards  for  such  work  products. 

l^ryieation  •  The  training  course  covers  all  topics  application  engineers  need  to  know 

Criteria  to  effectively  perform  ^plication  Engineering. 

•  The  material  in  the  training  courses  is  consistent  with  the  knowledge  and 
experience  in  management  and  engineering  of  the  anticipated  attendees. 

3.  PROCESS  DESCRIPTION 

The  Process  Support  Development  Activity  consists  of  all  activities  necessary  to  create  appropriate 
Process  Support  consistent  with  the  Process  Requirements  for  the  domain.  In  many  respects,  tUs  ac¬ 
tivity  involves  work  which  is  similar  to  that  of  a  conventional  software  development  project.  You  docu¬ 
ment  the  standards  and  procedures  that  establish  how  Application  Engineering  is  to  be  practiced.  You 
develop  training  courses  and  other  support  documentation  that  is  used  by  the  project  support  staff  in 
helping  projects  use  the  domain  product  effectively.  Furthermore,  if  you  decide  to  automate  some  or 
all  of  the  implication  Engineering  process  (i.e.,  create  an  Application  Engineering  Environment), 
then  you  apply  software  development  methods  to  accomplish  that  goal.  The  Process  Support 
Development  Activity  consists  of  the  five  steps  shown  in  Figure  DE3.2-1. 

3.1  Procedure 

Follow  these  steps  for  the  Process  Support  Development  Activity.  Perform  these  steps  in  the  order 
listed  but  iterate  through  them  until  you  are  satisfied  with  the  work  product  as  a  whole. 

Step:  Document  the  Application  Engineering  Process  Standard 

Action  Document  the  standard  policies  and  procedures  by  which  an  application 

engineer  develops  applications  in  the  domain. 

Input  Process  Requirements 

Result  Application  Engineering  Process  Standard 

Heuristics  •  The  Process  Requirements  defines  the  essentials  of  the  Application 

Engineering  process.  The  Process  Standard  cannot  conflict  with  the  Pro¬ 
cess  Requirements,  but  you  will  need  to  extend  the  Process  Standard  to 
provide  a  complete  process  description.  The  degree  to  which  you  plan  to 
automate  the  process  is  a  major  factor  in  how  you  elaborate  Process  Re¬ 
quirements  into  a  Process  Standard. 

•  This  document  elaborates  the  essentials  presoibed  by  the  Process 
Requirements  to  establish  the  specific  fi'amework  of  the  implication  Engi¬ 
neering  process.  Your  description  of  the  process  should  define  what  has  to 
be  done,  why  it  has  to  be  done,  and  who  completes  the  work.  You  should 
provide  procedures  that  explain  how  to  complete  the  process  (the  se¬ 
quence  of  tasks  or  task  steps  that  have  to  be  performed),  when  the  work 
is  performed,  and  the  criteria  for  measuring  the  quality  of  the  work. 
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•  The  purpose  of  standards  is  to  prcunote  a  oonastent  approi^  in  the 
develofMnent  of  ^)fdication  fvoducts.  Your  descripti<Mi  of  the  standards 
should  incorporate  the  stan^ds  used  by  your  organization  as  well  as 
cover  detailed  process  requirements. 

Step:  Develop  the  ^plication  Engineering  User’s  Guide 

Acdon  Create  a  detailed  guide  for  af^lication  engineers  ^di  instructs  them  on  how 

to  perform  every  aspect  of  Application  Engineering  including  manual  steps 
and  effective  use  of  any  automated  mechanisms. 

Input  •  Process  Requirements 

•  Application  ^igineering  Process  Standard 

Result  ^lidication  Engineering  User's  Guide 

Heuristics  •  Describe  all  aspects  of  performing  the  Application  Engineering  process  in 

the  User’s  Guide.  This  description  should  be  sufficient  for  experienced  ap¬ 
plication  engineers  to  understand  and  follow  the  jx-ocess  routinely  (i.e., 
without  assistance  after  initial  training)  and  effectively.  Within  tl^  de¬ 
scription,  oplain  effective  use  of  the  automated  medu^ms  provided  by 
the  Application  Engineering  Environment. 

•  Determine  the  degree  to  v^ch  the  Application  Engineering  process  is 
automated.  Indicate  additional  aspects  of  the  Ap|dication  Ei^eering 
process  to  automate  (beyond  vdiat  Process  Requirements  and  the  Process 
Standard  prescribe).  Your  guidance  to  the  application  engineer  must  re¬ 
flect  this  decision.  The  choice  of  appropriate  automation  is  governed 
Process  Requirements,  economics,  and  human  factors: 

-  Process  Reqitirements.  The  Process  Requirements  may  dictate 
preferences  on  process  and  presentation  automation  medianisms. 
For  example,  it  may  dictate  display  of  certain  information  in  a 
graphical  form  or  the  extent  of  automated  support  for  Application 
Modeling.  If  Process  Requirements  imposes  such  preferences,  you 
must  either  implement  them  or  refer  dianges  to  the  Process 
Requirements  Activity. 

-  Gnomics.  You  must  determine  whether  reduced  ^^lication 
Engineering  effort  will  be  suffident  to  justify  the  cost  of  automat¬ 
ing.  That  cost  may  indude  the  acquisition  of  software  tools  and 
hardware  for  application  engineering  projects,  as  well  as  the  devel¬ 
opment  resources  (both  time,  people,  and  material)  from  your  or¬ 
ganization.  Additionally,  you  must  also  consider  the  costs  of 
maintaining  and  enhancing  this  automated  support. 

-  Human  Factors.  Manual  procedures  are  usually  labor-intensive 
and  can  result  in  many  errors  being  introduced  during  any  aspect 
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of  Application  Engineering,  particularly  in  the  A|^lication  Pro- 
duction  {^lase.  A  i^oject  may  lose  mudi  time  trying  to  identify  and 
correct  errors,  and  then  repeating  the  process  from  where  the  last 
error  was  introduced.  Automation,  whether  specially-built  or  a 
commercial  tool,  can  reduce  the  effort  needed  during  labor-inten¬ 
sive  activities.  It  can  also  help  to  rediice  or  eliminate  errors  in  the 
process.  Another  benefit  of  using  automation  is  to  reduce  training 
requirements  for  the  application  engineering  staff.  Fbr  example, 
a  i^oject  may  need  more  training  to  perform  Apjdication  Modeling 
manually  than  if  automated  support  were  provided. 

•  Decide  what  expertise  and  experience  application  engineers  are  expected 
to  have.  Write  the  User’s  Guide  with  the  perspective  and  assumptions  that 
people  with  that  expertise  should  have. 

•  Provide  whatever  domain  knowledge  application  engineers  will  need  to 
perform  Application  Engineering  correctly  and  efiectively.  You  should 
consider,  as  a  minimum,  paraphrasing  the  Product  Requirements  in  a  form 
usable  by  application  en^eers.  This  information  will  help  application  en¬ 
gineers  understand  the  implications  of  decisions  to  be  made  in  Application 
Modeling. 

•  Desaibe  what  the  application  engineer  should  do  when  confronted  with 
a  problem  during  Application  Engineering.  Include  descriptions  of 
common  mistakes  and  toown  bugs  (and  corresponding  work-arounds). 

•  Provide  advice  to  the  application  engineer  on  how  to  build  systems  with 
particular  characteristics  (e.g.,  particular  capabilities  or  performance). 
Explain  the  meaning  and  purpose  of  different  Application  Models  that 
could  be  developed. 

Step:  Develop  the  Application  Engineering  Environment 

Action  Design,  implement,  and  verify  the  automated  mechanisms  needed  to  support 

the  Application  Engineering  process. 

Input  •  Application  Engineering  User’s  Guide 

•  Product  Implementation 

Result  Application  Engineering  Environment 

Heuristics  •  The  Application  Engineering  User’s  Guide  specifies  what  aspects  of  the 

Application  Engineering  process  are  automated.  Revise  the  User’s  Guide 
if  this  cannot  be  fully  satisfied. 

•  Creating  an  Application  Engineering  Environment  is  a  software  develop¬ 
ment  task.  You  must  design  an  environment,  implement  that  design  in  a 
programming  language  (or  via  equivalent  commercially-available  soft- 
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ware  technology),  and  test  it  to  verify  that  the  resulting  environment  im¬ 
plements  the  ^i^lication  Engineering  User's  Guide  correctly. 

•  Reduce  your  up-front  development  costs  by  taking  advantage  of  available 
technology  to  automate  various  activities  within  the  infrastructure.  For  ex¬ 
ample,  there  are  planning  and  scheduling  tools  for  project  management; 
object-oriented  databases  and  user  interface  tools  that  can  suf^rt  speci¬ 
fying  an  Application  Model;  testing,  prototyping,  and  environment  simu¬ 
lation  tools  for  validation;  simulation  and  dynamic  assessment  tools  for 
assessment;  and  metaprogramming  and  system  generation  tools  for  prod¬ 
uct  generation.  However,  you  must  also  consider  \^at  resources  you  will 
need  to  integrate  these  or  other  technologies  into  a  coherent 
infrastructure. 

•  Consider,  as  a  minimum,  automating  the  specification  task  of  the  >^}{dication 
Modeling  Activity  and  the  implication  Production  Activity.  These  are  the 
core  of  Application  Engineering  and  provide  the  most  direct  benefits. 

•  Decide  what  code  construction  tools  (e.g.,  compiler,  linker,  debugger)  will 
be  used  by  application  engineers  to  construct  Application  Product  Soft¬ 
ware.  For  code  components,  you  must  consider  factors  such  as  target  hard¬ 
ware  and  operating  system  and,  if  different  from  the  host  environment, 
how  the  code  will  be  tested  (e.g.,  in  a  host-simulated  target  environment 
or  directly  in  the  target  environment)  and  aeated  in  executable  form  for 
the  target  environment  (e.g.,  cross-compilers). 

•  Consider  how  the  Generation  Procedure  fits  into  this  environment  Rom  the 

perspective  of  Rocess  Support,  a  Generation  Rocedure  is  a  blade-box  that 
can  apply  the  decisions  resolved  Ity  an  Application  Model  to  Adaptable  Com¬ 
ponents  to  (xeate  Roduct  ^ftware.  If  automated  input  of  an 

imputation  Model  is  not  supported,  then  additional  effort  is  required  from 
the  application  engineer  to  transform  his  mpUtation  Model  into  a  form  suit¬ 
able  for  use  by  the  Generation  Rocedure. 

Step:  Develop  the  Application  Engineering  Environment  Support  Manual 

Create  a  manual  that  defines  the  information,  resources,  and  steps  required 
to  install  the  Application  Engineering  Environment  for  use  by  a  project. 

Application  Engineering  Environment 

Application  Engineering  Environment  Support  Manual 

Describe  installation  instructions  for  the  automated  mechanisms  of  the 
environment.  These  instructions  are  spedfic  to  your  organization.  However, 
consider,  at  a  minimum: 

•  Inventory.  This  is  a  list  of  all  materials  (code,  software  utilities, 
documentation)  to  be  provided  to  the  Roject  Support  Activity. 


Action 

Irqwt 

Result 

Heuristics 
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•  DistritutiMMtdki  This  describes  the  media  and  formation  which  the 
automated  mechanisms  are  provided  to  Project  Siq)port  (e^  tape, 
(&k).  It  shoukl  ako  deacrije  hew  to  odaract  the  oontenis  from  the  medium. 

•  AuiUProc«hir».  These  are  instructions  on  how  to  build  the  autennated 
environment  from  suited  source  code. 

•  S^i/bDoreJtoourcer.  These  describe  software  resources  needed  to  build 
and  execute  the  auhxnated  mechanisms  (e^  (^aerating  syston,  oompQ- 
er,  suppcMtingutility  programs,  vendern  numbers).  These  also  identify  die 
vendor  and  vnsion  of  any  ocmunercialfy  siqipcvted  off-die-shdlf  st^tware 
that  supports  portions  of  the  environment 

•  Hardware  Resources,  These  desoibe  the  host  (datforms  on  which  the 
environment  can  successfully  execute  (e.g.,  CPU,  operating  system). 

•  Limitations.  These  describe  known  discrepancies  or  unimplemented 
features  in  the  delivered  environment  and  any  known  workarounds. 

Step:  Develop  'Draining  Courses 

Action  Develop  courses  to  train  managers  and  application  engineers  in  the  effective 

use  of  Ae  application  engineering  process  and  supporting  mechanisms. 

frpur  •  Application  Engineering  Process  Standard 

•  Application  Engineering  User’s  Guide 

•  Application  Engineering  Environment  Support  Manual 

Result  Application  Engineering  H’aining  Courses 

Heuristics  The  content  of  these  courses  will  be  determined  by  how  much  expertise  your 

organization  believes  application  engineers  need  to  practice  Application 
Engineering  effectively  and  correctly.  You  should  consider,  at  a  minimum,  the 
following  topics: 

•  How  to  build  systems  in  your  domain  using  the  ^>{dication  Engineering 
process. 

•  How  to  manage  application  engineering  projects  successfully. 

•  How  to  use  the  automated  capabilities  of  the  implication  Engineering 
Environment. 

3.2  Risk  Management 

JZfrk  'The  mi^cation  Ei^eering  process  wOl  be  inoemtistent  with  the  Rooess 

Requironoits. 
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Implication 


Fisk 

Impliaition 

Actuation 


Sisk 


Implication 


Mitigation 


Application  engineers  may  not  be  able  to  {Mroduce  applications  that  satisfy 
customer  requirements. 

Review  the  Process  Standards  with  e:q)erienced  managers  and  engineers  to 
check  viabilify.  Review  the  design  and  use  of  automated  medianisms  with 
experienced  engineers  to  ensure  that  those  mechanisms  satisfy  the  Process 
Requirements  and  Process  Support  documentation. 

Automation  will  not  address  the  major  difficulties  of  engineering  aj^lications 
in  a  domain. 

The  Application  Engineering  process  will  be  too  labor-intensive,  error-prone, 
or  difficult,  inCTcasing  the  cost  required  to  build  an  application. 

•  Review  other  Application  Engineering  processes  to  see  what  areas  were 
automated  and  the  rationale  for  doing  so. 

•  Review  past  implication  Engineering  process  efforts  from  other,  similar 
domains  to  see  what  areas  of  difficulties  were  encountered  and  how  they 
were  resolved. 

•  Measure  and  analyze  the  performance  of  the  implication  Engineering 
process  to  help  identify  deficiencies. 

The  Application  Engineering  process  will  be  hard  to  follow  (i.e.,  vague, 
incomplete). 

Application  engineers  will  have  a  difficult  time  developing  applications.  This 
may  cause  excessive  use  of  the  project  support  staff.  It  may  also  cause  incorrect 
applications  to  be  developed  and  increase  the  time  required  to  deliver  an 
acceptable  product  to  the  customer. 

Review  the  Process  Support  documentation  with  application  engineers  to  see 
what  areas  of  the  process  are  incomplete,  inconsistent,  or  ambiguous.  Have 
them  generate  example  work  products,  noting  where  they  misinterpret  or 
misuse  the  documentation. 


4.  INTERAOTONS  WITH  OTHER  ACTIVITIES 


4.1  Feedback  TO  Information  Sources 

Contit^emy  The  Process  Requirements  work  product  is  incomplete,  ambiguous,  or 

inconsistent. 

Source  Process  Requirements  Activity 

Refuse  Describe  specifically  where  the  Process  Requirements  work  product  is 

inadequate  and  suggest  improvements.  Proceed  with  the  implementation  of 
Process  Support  as  far  as  possible  while  the  Process  Requirements  are  being 
updated. 
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ComtiKtmeif  The  Oeneratioa  R’ooechare  cannot  be  used  in  its  amtei  form  hi  die 

^)ldicatk>n  Enginemng  process. 

% 

Source  Gei^ration  Implementati<m  Activity 

Reepmse  Describe  how  the  Generation  Procedure  needs  to  be  changed  so  that  it  will  fit 

within  the  Aj^cation  Engineering  process. 


4.2  Feedback  From  PRODiKn*  Consumers 


Contiagmcy 

Source 

Besponse 

Contu^ency 

Source 

Requmse 

Contit^ency 

Source 

Beqwnse 


The  .^^lication  Engineering  fu-ocess  is  difficult  to  use  or  is  too 
labor-intensive. 

Project  Support  Activity 

Identify  vriiere  the  prc^lems  exist  and  discuss,  with  the  ap[dication  engineers, 
ways  of  reducing  (or  eliminating)  these  juroblems  (e.g.,  throi^  the  use  of 
automation). 

Suggestions  are  made  to  automate  various  aspects  of  the  >^lication 
Engineering  process. 

Project  Support  Activity 

Consider  the  economic  and  human  factors  to  help  you  decide  whether  to 
pursue  automating  the  suggested  areas  of  the  A^lication  Engineering 
process. 

The  Domain  Spedfication  is  not  satisfied. 

Domain  Verification  Activity 

•  Correct  errors  as  part  of  the  next  iteration  of  Process  Support  Devdopmrat 

•  Refer  capabilities  that  cannot  be  supported  to  Domain  Analyris  for 
revision. 


DE.4.  PROJECT  SUPPORT  ACnVITY 


1.  GETTING  STARTED 

The  Project  Support  Activity  is  an  acdvi^  of  Domain  EngineMing  fix  valktotiQg  En^neering 

Process  SuppcMt  and  assisting  projects  in  its  use.  Application  Engineering  Process  Support  is  tlw  ap¬ 
plication  engineering  name  for  the  Domain  Implementation,  lb  ensure  that  the  baselined  Domain 
Imjdementation  is  usable  and  effective.  Project  Support  independently  validates  it  frcnn  the  perspec¬ 
tive  of  the  product  and  process  needs  of  the  targeted  apj^cation  engineering  {vojects.  Project  Support 
assists  apidication  engineers  in  effective  use  of  the  process  and  supporting  materials,  through  deliwiy 
and  installation,  training,  and  consultation  for  the  targeted  project  Project  Support  trains  apfdication 
ei^eers  inhiow  to  perform  the  pr  esoibed  Application  Engineering  process,  using  any  accompaitying 
automated  stq)poit,  and  answers  questions  about  the  process,  its  documentation,  and  its  automation. 
Based  on  issues,  problems,  and  future  needs  identified  by  application  engineers.  Project  Support  coor¬ 
dinates  feedback  to  the  rest  of  Domain  Engineering  for  improvements  in  the  supported  jvocess  or 
products  o(  triplication  engineering. 

LI  Objectives 

The  objectives  of  the  Project  Support  Activity  are  to: 

•  Evaluate  the  effectiveness  and  quality  of  Donuun  Implementation  for  use  tty  air^cation 
engineering  projects 

•  Provide  customer  support  to  application  engineering  projects  in  the  understanding  and  use  of 
IXxiiain  Implementation 

•  Provide  aconduitbywhidi  the  needs  of  application  engineering  projectscan  influence  domain 
improvements  and  evolution 

IJ,  REQUHED  iNFORMiOION 

The  Project  Support  Activity  requires  the  following  information: 

•  D(»nain  Definition 

•  Domain  Implementation 

13  Requibed  Knowledge  AND  Experience 

The  Project  Support  Activity  requires  domain  and  software  knowledge  and  oqierience  in: 
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•  The  methods,  practices,  and  scrfuticMis  o(  apphcatkm  devdc^ment  in  the  domain 

•  Installing  and  evaluating  software  (voducts  and  their  documentation 

•  Developing  and  teadiing  training  courses 

•  Assisting  engineers  and  managers  in  the  use  of  jarocess  documentation  and  automation 

2.  PRODUCT  DESCRIPnON 

The  Project  Support  Activity  produces  no  work  products.  Instead,  it  is  a  service  activity  to  application 
engineering  projects  within  the  domain. 

3.  PROCESS  DESCRIPTION 

The  Project  Support  Activity  consists  of  two  steps  shown  Hgure  DE.4-1.  The  first.  Domain  \^idation, 
is  ongoing  and  must  certify  each  baseline  Domain  Implementation  as  it  becomes  available.  The  se¬ 
cond,  Domain  Delivery,  is  initiated  at  the  beginning  of  eadi  targeted  application  engineering  project 
and  continues  until  that  project’s  termination. 


Figure  DE.4-1.  ftoject  Support  Eroces 

3.1  Procedure 

Fbllow  these  steps  for  the  Project  Support  Activity. 

Step:  Domain  Validation  Activity 

Action  Certify  that  baselined,  deliverable  Domain  Implementation  will  satisfy 

application  engineering  projects’  needs,  as  specified  in  the  Domain  Definition 
(available  in  future  releases). 

Input  •  Domain  Definition 

•  Domain  Implementation 

BesuU  None 
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Heuristics  •  Review  the  Domain  Plan  and  Domain  Definition  from  the  perspective  (rf 

aj^cation  engineering  projects.  Ensure  that  the  product  and  process 
needs  of  projects  are  properly  rein-esented.  Advise  the  rest  of  Dtnnain  En¬ 
gineering  on  the  realistic  {M’oduct  and  process  needs  of  af^cation 
engineering  projects. 

•  Perform  an  independent  evaluation  of  each  baseline  of  the  Domain 
Implementation  as  it  becomes  available.  Evaluate  whether  it  propetiy  sat¬ 
isfies  and  balances  the  intended  mix  of  general  business  objectives  and 
specific  application  engineering  project/customer  needs. 

•  Perform  independent  validation,  including  extensive,  scenario-based 
testing  of  the  (integrated)  Product  Implementation  and  Application  Engi¬ 
neering  Environment  portions  of  the  £>omain  Implementation  baseline. 
Evaluate  the  correctness  and  usability  of  the  Application  Engineering 
User’s  Guide  and  Application  Engineering  Environment  Support  Manual 
as  they  relate  to  use  of  the  Product  Implementation  and  A{^lication 
Engineering  Environment. 

•  Attempt  to  build  typical  products  that  reflect  realistic  project  experience 
on  existing  systems  in  the  domain.  Identify  capabilities  or  diaracteristics 
of  those  products  that  the  Domain  Definition  accommodates  but  that  are 
not  attainable  with  the  provided  Domain  Implementation  baseline. 

•  Evaluate  the  impact  of  the  Domain  Implementation  baseline  on  the 
efficiency  and  effectiveness  of  application  engineering  projects.  Identify 
improvements  in  realistic  and  practical  Domain  Implementation  usabilify. 

Step:  Domain  Delivery  Activity 

Deliver  Domain  Implementation  to  an  application  engineering  project,  assist 
with  its  use,  and  identify  needed  product  or  process  improvements  (available 
in  future  releases). 

Domain  Implementation 

None 

•  Initiate  an  instance  of  this  activity  upon  creating  each  targeted  application 
engineering  project;  continue  this  activity  until  the  project  terminates. 

•  Provide  copes  of  pocess  documentation  (i.e.,  the  Application  Engineering 
Process  SUmdard  and  the  ^plication  Engineering  User’s  Guide)  to  the  en¬ 
gineers  and  managers  of  the  application  engineering  project. 

•  Install  the  ^>plication  Engineering  Environment  (and  subsequent 
upgrades),  induding  the  Adaptable  Components  from  the  Prt^uct 
Implementation,  for  project  tise  and  check  it  for  proper  operation.  Follow 
installation  pocedures  documented  in  the  Application  Engineering 
Environment  Support  Manual. 


Action 

Input 

Result 

Heuristics 
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•  Use^ppUcatkmEngineerii^lhuniiigCbursestoprcivklefoiTnalinAruction 
to  api^ication  engineers  (including  project  managers)  in  the  proper  and 
effective  use  of  the  A{^cation  Engineering  process  and  the  associated  Pro¬ 
cess  Support  and  Product  Impriementation  wcvk  products.  Exi:dain  use  of  the 
Application  Engineering  Process  Standards  and  Procedures  for  under¬ 
standing  of  the  process  in-the-large  and  the  Application  Engineering 
User’s  Guide  for  understanding  and  performing  the  process  in-the-small. 
Explain  the  use  of  the  Application  Engineering  Environment  as  described 
in  the  User’s  Guide. 

•  Provide  consultation  services  to  application  engineers  as  they  perform 
Application  Engineering.  Consulting  requires  extensive  domain  knowl¬ 
edge  to  answer  application  engineers’  questions  accurately  and  fully.  Con¬ 
sultants  should  be  knowledgeable  in  all  aspects  of  Domain  Implementa¬ 
tion.  There  also  needs  to  be  a  core  of  expert  consultants  who  are 
sufficiently  familiar  with  other  domain  engineering  work  jn-oducts  to  pro¬ 
vide  complete,  detailed,  in-depth  information,  rationales,  and  assistance 
when  complex  problems  are  encountered  by  a  project.  In  small  organiza¬ 
tions,  the  entire  domain  engineering  team  may  be  called  on  as  a  consulting 
resource. 

•  In  response  to  the  delivery  services  provided,  application  engineers  will 
identify  problems,  improvements,  and  future  needs  that  Domain  Engi¬ 
neering  should  consider  for  possible  action.  Some  of  these  ideas  will  relate 
directly  to  meeting  customers’  needs  while  others  will  relate  to  how  effi¬ 
ciently  application  engineers  can  use  the  process  and  associated  domain 
assets.  Itoperly  record  and  communicate  these  ideas  and  their  motiva¬ 
tions  to  the  rest  of  Domain  Engineering  as  feedback  from  application  engi¬ 
neering.  This  is  a  key  part  of  Project  Support  and  is  essential  to  continual 
project  and  market  responsive  improvement  and  evolution  of  a  domain. 


3.2  Risk  Management 


Sisk  The  needs  of  a  particular  application  engineering  project  will  conflict  with  a 

simple  interpretation  of  prescribed  standards  and  procedures. 

In^Ucation  The  project  will  be  forced  to  work  in  conflict  with  that  interpretation  and  to  be 

less  effective  and  efficient. 


Mtigation  Ify  to  interpret  standards  and  guidelines  flexibly  so  that  they  best  fit  the  needs 

of  each  project.  Be  aware  of  variations  in  the  Process  Support,  particularly  in 
environment  installation,  that  support  different  needs.  Ihilor  consultation  and 
training  to  each  particular  project’s  needs. 

Ride  Changes  in  the  circumstances  of  a  project  may  conflict  with  the  previous 

interpretation  of  prescribed  standards  and  proc^ures. 

Implication  The  project  will  be  forced  to  work  around  obsolete  support  and  will  be  less 

effective  and  efficient  than  necessary. 
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MUfatim  Reconsider  the  siq)poit  given  to  a  project  whenever  drcumstanoes  change 

signifkantly.  Be  prepared  to  adjust  the  environment,  trahuqg,  andconniltiiig 
advice  to  fit  current  needs  better. 

4.  INTEIUCnONSWIlH  OTHER  ACnvm^ 


4bl  Feedback  TO  Information  SooRCBS 


Contingmqf 

Soux* 

ttsponsc 


Omtingeniy 

Source 


CotUirgency 


Ap{^cation  engineers  are  havii^  difficulty  using  the  i^iplkatkm  Ei^jneering 
process  or  Domain  Imfriementatkm  to  d^k^  i^iplicatxms. 

Process  Support  Devek^ment  Activity 

•  Suggest  better  ways  to  the  project  for  performing  the  process  within  the 
prescribed  standards. 

•  Document  the  nature  of  the  difficulties  and  suggest  improvements  in  the 
prescribed  [vocess  or  in  its  documentation,  autcxnation,  or  training. 

Particular,  noncommon  customer  requirements  cannot  be  oppressed  in  an 
^iplication  Model. 

•  Domain  Definition  Activity 

•  Process  Requirements  Activity 

•  Process  Su{^rt  Develo|xnent  Activity 

•  Identify  unrecognized  domain  variations  that  ai^cation  engineers  need. 

•  Suggest  to  the  project  how  it  can  best  work  around  current  limitations. 

Projects  cannot  build  applications  that  provide  required  behavior  or  that 
satisfy  required  constraints  on  resource  usage  (e.g.,  time,  space,  reliability). 


Source  •  Domain  Analysis  Activity 

•  Domain  Implementation  Activity 

Aaponse  •  Document  the  requirements  or  constraints  that  cannot  be  satisfied. 

•  Suggest  to  the  [voject  how  to  best  remetfy  the  behavior  or  resource  usage. 


4J2  Feedback  From  Product  Consumers 
None 
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AE.  APPLICATION  ENGINEERING  OVERVIEW 


1.  GETTING  STARTED 

Application  Engineering  is  a  Synthesis  process  for  creating  and  supporting  an  application  product  that 
satisfies  specified  customer  requirements.  A  product  is  represented  by  a  set  of  associated  work  prod¬ 
ucts  that  result  from  analysis  of  those  requirements,  ^plication  Engineering  is  diaracterized  by  a 
comprehensive  life-t^cle  process  for  the  management,  analysis,  production,  and  support  of  the  mem¬ 
bers  of  a  product  family.  This  is  similar  in  piu’pose  to  a  conventional  software  development  process, 
but  is  tailored  to  the  problems  and  the  needs  of  projects  in  a  particular  business  area.  Such  a 
business-area  focus  allows  for  the  systematic  reuse  of  standardized  work  products  within  and  among 
projects  in  that  business  area. 

Domain  Engineering  identifies  a  set  of  characteristic  decisions  for  a  business  area  that  determine  how 
a  product  can  be  tailored  to  meet  particular  needs.  It  also  provides  standardized  work  products  in  a 
form  that  supports  tailoring  to  thv  isc  decisions.  Application  engineering  concentrates  on  the  analysis 
of  customer  requirements  to  resolve  those  decisions.  The  result  is  a  model  of  a  corresponding  product 
that  can  be  evaluated  according  to  those  requirements.  When  a  model  is  found  to  be  acceptable,  it  is 
used  to  drive  the  generation  of  tailored  work  products  that  implement  the  model.  After  the  resulting 
work  products  are  verified  to  the  model,  they  are  delivered  to  customers  for  further  evaluation  and 
u.se. 


1.1  Objectives 

The  objectives  of  Application  Engineering  are  to: 

•  Understand  the  needs  of  customers,  balancing  concerns  of  cost  versus  value,  to  produce  a 
product  that  fulfills  those  needs  most  effectively 

•  Organize  and  direct  resources  for  the  production  and  support  of  the  product 

•  Produce  software  and  documentation  that  support  the  delivery  and  use  of  the  product 

•  Leverage  standardized  process  and  work  products  for  a  domain  to  produce  required  results 
effectively,  predictably,  and  profitably 

1.2  Required  Information 

Application  Engineering  requires  the  following  information: 


Application  Engineering  Process  Support 
Customer  requirements 
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U  Required  Knowledge  AND  Experience 

Application  Engineering  requires  domain,  business,  and  software  knowledge  and  eq)erience  in: 

•  The  problems  that  the  products  in  the  domain  are  intended  to  solve  and  the  engineering 
tradeoffs  to  be  considered  in  creating  a  viable  solution 

•  Understanding  and  interpreting  customer  requirements  and  developing  applications  that 
satisfy  those  requirements 

•  The  management,  production,  and  delivery  of  software  work  products 

•  How  to  use  the  Application  Engineering  Process  Support  to  develop  an  application 

•  The  information  required  by  the  ^plication  Engineering  process  employed  by  the  project 

2.  PRODUCT  DESCRIPTION 

Application  Engineering  creates  four  work  products: 

•  Project  Plan.  The  Project  Plan  establishes  standard  practices  and  procedures  and  defines  tasks 
for  incremental  development  with  milestones  and  resource  allocations. 

•  Application  Model.  The  Application  Model  describes  a  deliverable  system  in  terms  of 
requirements  and  engineering  decisions. 

•  Application  Product.  The  Application  Product  consists  of  an  application  and  associated  user 
documentation  work  products.  It  is  derived  mechanically  from  the  Application  Model  to 
provide  a  capabilify  spedfied  customer  requirements. 

•  Delivery  Support.  Delivery  Support  includes  testing,  installation,  and  training  materials.  It  is 
derived  mechanically  to  be  consistent  with  the  Application  Model  to  support  the  delivery  of 
the  Application  Product. 

3.  PROCESS  DESCRIPTION 

The  Application  Engineering  process  defined  here  is  prototypical  in  the  sense  that  an  objective  of 

Domain  Engineering  is  to  define  such  a  process  tailor^  to  the  needs  of  a  domain.  This  ^plication 

Engineering  process  consists  of  the  four  activities  shown  in  Figure  AE-1. 

3.1  Procedure 

Step:  Project  Management  Activity 

Action  Plan,  monitor,  and  control  project  resources  to  deliver  a  product. 

Input  Customer  requirements 

Project  Plan 


Readt 


AB.Ap|<Bilio«E«|i««efi«t<XiMviw» 


Heuristics 


Qmomer 

RequiremeaU 


Figure  AE>1.  Aftototypical  AppUcatkaEagmceringlhooess 

•  Institute  polides  and  procedures  in  accordance  with  the  Application 
Engineering  Process  Standard  of  Application  Engineering  Process  Sup¬ 
port.  Allocate  time  and  budget  for  personnel  to  receive  needed  training  in 
use  of  Application  Engineering  l^ocess  Support.  Domain  Engineering 
Project  Support  staff  will  deliver,  including  installing  automation,  and 
support  effective  use  of  Application  Engineering  Process  Support. 

•  Create  a  plan  that  reflects  the  process  defined  and  supported  by 
Application  Engineering  Process  Support  Revise  the  plan  to  reflect  imex- 
pected  progress  or  delays. 

•  For  more  accurate  monitoring  and  control  of  the  effort,  set  spedfic, 
measmable  objectives  and  schedule  repeated  short  iterations  throu^  the 
process  to  achieve  them.  Build  the  required  product  incrementally  and  re¬ 
view  interim  capabilities  with  the  customer  and  users  in  order  to  maximize 
opportunities  for  feedback  that  can  ensure  timely  delivery  of  a  valid  result 

•  Coordinate  development  and  performance  of  the  jdan  with  Domain 
Management  both  to  exploit  ai^  forthcoming  domain  development  and  to 
schedule  domain  improvements  (in  {M'ocess  or  product)  needed  this 
project. 
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Step:  i^plicatioii  Modelii^  Activity 

Aakm  Resolve  dedsions  to  spedfy  a  required  j^oduct,  based  on  an  analysis  of 

customer  requirements,  and  evaluate  it  with  respect  to  customer  or  tedmical 
constraints  on  an  acceptable  solution. 

Input  Customer  requirements 

Ratdt  Application  Model 

Heuristics  •  The  User’s  Guide  of  Application  Engineering  Process  Support  defines  an 

application  modeling  process  for  products  within  a  domain.  This  [Mrocess 
provides  a  firamework,  notation,  and  mechanisms  for: 

-  Specification.  Analyzing  customer  requirements  and 
expressing  them  in  an  Application  Model  as  a  set  of  decisions 
that  descnbe  an  Application  Produd  which  should  satisfy 
those  requirements. 

-  Validation.  Evaluating  the  functional  adequacy  of  a  modeled 
^plication  Product  1^  analyzing  the  static  (consistency  and 
completeness)  and  dynamic  (execution  behavior  in  a  simu¬ 
lated  environment)  characteristics  implied  by  the  Application 
Model. 

-  Assessment.  Evaluating  relevant  properties  of  alternative 
i^lication  Models  to  determine,  qualitatively  and  quantita¬ 
tively,  whidi  will  result  in  a  system  that  best  satisfies  the  cus¬ 
tomer’s  operational  and  product  quality  requirements. 

The  Application  Engineering  Environment  provides  assodated 
automated  support  for  this  process. 

•  Perform  the  prescribed  application  modeling  process  to  create  an 
Application  Model  that  expresses  customer  requirements.  Extend  the 
model,  as  necessary,  to  reflect  engineering  decisions  needed  to  spedfy  a 
complete  product.  Review  your  understanding  of  those  requirements,  as 
expressed  in  the  model,  with  customer  (and  user)  representatives. 

•  Use  provided  mechanisms  to  specify,  validate,  and  assess  alternative 
^plication  Models  and  review  the  results  with  customer  representatives. 
If  one  of  the  provided  mechanisms  is  simulated  execution,  review  use  of 
the  simulated  application  with  customer  and  user  representatives. 

•  Based  on  your  perception  of  the  risks,  rapidly  build  an  approximate  (i.e., 
complete  but  inaccurate)  model  of  the  complete  product  or  partial  models 
of  poorly  understood  aspects  of  the  product.  For  parts  of  the  customer  re¬ 
quirements  that  are  incomplete  or  unclear,  aeate  alternative  (partial) 
models  that  can  be  compart  in  review  and  evaluation  with  the  customer. 
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•  If  the  implications  for  the  Application  Product  of  aspects  of  an  Apf^cation 
Model  are  not  clear,  seek  clarification  and  elaboration  firom  Domain  Engi¬ 
neering  Project  Support  staff.  Project  support  can  determine  how  deci¬ 
sions  (individually  and  in  combination)  affect  each  of  the  work  products 
that  will  make  up  the  Application  Product. 

•  When  some  aspect  of  customer  requirements  cannot  be  ejqnressed 
accurately  in  an  .^plication  Model  or  acceptable  properties  cannot  be  at¬ 
tained  for  the  product,  seek  Domain  Engineering  assistance.  For  particu¬ 
lar  problems,  there  may  be  workarounds  or  alternative  ways  of  describing 
particular  facets  of  the  product. 

Step:  Application  Production  Activity 

Create  a  standardized  product  and  accompanying  delivery  support  work 
products  in  accordance  with  an  Application  Model. 

Application  Model 

•  Application  Product 

•  Delivery  Support 

•  Application  Engineering  Process  Support  provides  a  mechanical,  possibly 
automated,  process  for  creating  an  Application  Product  and  Delivery  Sup¬ 
port,  given  a  valid  Application  Model  representing  customer 
requirements  and  engineering  decisions. 

•  For  each  work  product  that  makes  up  the  Application  Product  and 
Delivery  Support,  there  is  a  manual  (documented  in  the  User’s  Guide)  or 
automated  (implemented  in  the  Application  Engineering  Environment) 
generation  procedure,  driven  by  the  Application  Model,  for  constructing 
a  tailored  version  of  the  work  product. 

•  In  some  cases,  there  may  be  facilities  in  Application  Engineering  Process 
Support  for  special  component  implementation.  These  fadlities  support 
the  direct  construction  of  highly  variable  parts  of  particular  work  products 
without  violating  the  integrity  of  the  Application  Model.  Such  modifica¬ 
tions  generally  entail  greater  effort  and  risk  of  error,  both  initially  and 
when  requirements  change. 

Step:  Delivery  and  Operation  Support  Activity 

Action  Deliver  the  Application  Product  to  the  customer,  support  its  use,  and  evaluate 

its  effectiveness. 

Input  •  Application  Product 

•  Delivery  Support 


Action 

Injoft 

Result 

Heuristics 
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Result 


None 


Heuristics  •  Delivery  Support  provides  the  medianisms  needed  to  deliver  an 

Application  J^oduct  to  the  customer.  Delivery  includes  installing  the  Ap¬ 
plication  Product  into  its  operational  environment  and  training  users  in  its 
operation.  Procedures  for  accomplishing  this  are  part  of  the  User’s  Guide 
of  Application  Engineering  Process  Support  with  additional  specifics 
included  as  part  of  Delivery  Support. 

•  Application  engineers  provide  consulting  assistance  as  needed  for  users  to 
become  effective  with  the  Application  Product.  This  encompasses  both  ini¬ 
tial  training  and  subsequent  troubleshooting  if  unexpected  behaviors  are 
detected. 

•  Operation  support  includes  analyses  of  the  effectiveness  of  the 
Application  Product  for  users,  ^plication  engineers  should  identify  and 
document  any  problems  encotmtered  and  any  additional  or  changed  needs 
revealed  as  the  implication  Product  is  used. 

3.2  Risk  Management 

None 

4.  INTERACTIONS  WITH  OTHER  ACTTVITIES 
4.1  Feedback  TO  Information  Sources 

Contit^ency  The  standardized  product  family  is  inadequate  to  support  the  needs  of 

particular  customers. 

Source  Domain  Engineering 

Response  Describe  why  the  standardized  product  family  is  deemed  inadequate,  and 

suggest  how  it  can  be  improved. 

Contingency  The  standardized  Application  Engineering  process  is  inefficient  or  leads  to 

less-than-ideal  results  for  this  project. 

Source  Domain  Engineering 

Reqwnse  Describe  why  the  standardized  ^plication  Engineering  process  is  deemed 

inefficient  or  inadequate,  and  suggest  how  it  can  be  improved. 

Contingency  The  Application  Engineering  Process  Support  provided  is  incomplete  or 

deficient. 

Source  Domain  Engineering 

Response  Describe  the  inadequacies  in  the  Application  Engineering  Process  Support. 

Indicate  which  sections  are  incomplete  or  deficient.  These  may  indude: 
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missiiig  work  product  families,  an  uKXxnfdete  User's  Guide,  errws  in  the 
User's  Guide,  imf^operly  described  Adaptable  Components,  fMlfiinctirtning 
generation  procedure(s),  and  bugs  in  interface  softwve  iHt>vided  by  Domain 
Engineering. 

4.2  Feqdback  From  Product  Consumers 

Con^igeacy  The  customer  requests  new  or  modified  capabilities  for  the  system. 

Source  Customer 

Response  •  Build  a  new  version  of  the  system. 

•  Reject  the  suggestions  as  out  of  scope. 

•  Ask  Domain  Engineering  to  make  necessary  changes  in  the  domain. 

Contingency  The  customer  identifies  system  anomalies,  changes  to  the  target  environment, 

inadequate  system  performance,  or  inadequate  reliability. 

Source  Customer 

Response  •  Correct  system  anomalies,  accommodate  dianges  to  the  target 

environment,  tune  the  system. 

•  Reject  changes  as  out  of  scope. 

•  Ask  Domain  Engineering  to  make  necessary  changes  in  the  domain. 
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APPENDIX:  MATURITY  ASSESSMENT  AND 
FUTURE  EVOLUTION 

This  is  the  first  release  of  the  Reuse-Driven  Software  Processes  Guidebook.  This  release  desoibes 
two  reuse-driven  software  processes  that  are  oriented  toward  different  stages  of  reuse  capability  from 
the  perspective  of  the  Consortium’s  RCM.  Acomplete  Reuse-Driven  Software  Processes  Guidebook 
woidd  describe  a  continuum  of  reuse-driven  softie  processes  from  which  an  organization,  at  any 
stage  of  reuse  capability,  could  derive  the  definition  of  a  suitable  process  for  that  organization. 

As  a  whole,  the  Consortium  considers  the  opportunistic  process  description  in  Part  Opp  of  this 
guidebook  to  be  at  the  exploratory  level  in  the  following  maturity  sdieme.  The  leverag^  process 
desCTiption  in  Part  Lev  is  approaching  the  developmental  level  in  the  following  maturity  scheme: 

•  Exphratory.  Many  sections  are  immature,  incomplete,  or  missing;  incomplete  sections  are 
limited  in  detail. 

•  Devdopmental.  All  sections  are  present  but  some  are  incomplete;  complete  sections  have  been 
used  on  at  least  one  pilot  project  or  case  study. 

•  FunctionaL  All  sections  are  complete  and  have  been  independently  validated  in  use  on  several 
pilot  projects. 

•  Production.  All  sections  are  complete,  validated,  and  constitute  a  mature  representation  of 
organizational  policies  and  concerns. 

lb  advance  beyond  functional-level  maturity,  the  guidebook  must  be  refined  to  meet  particular 
standards  for  production  use  in  a  particular  organization.  Quality  improvements  can  continue  based 
on  organizational  experience  with  using  it. 

The  Consortium  will  continue  to  refine  the  guidebook  until  all  its  sections  reach  functional-level 
maturity.  This  goal  assumes  pilot  project  participation  by  government  and  industrial  organizations. 
Such  participation  is  essential  to  improving  the  depth  and  quality  of  the  guidebook. 

At  this  stage,  the  Consortium  considers  the  guidebook  to  be  usable  in  the  following  ways: 

•  On  pilot  and  low-risk  production  projects 

•  Under  the  guidance  of  a  technologist,  acting  as  a  transfer  agent,  who  can  interpret,  elaborate, 
and  fill  in  guidebook  material  sufficiently  for  other  partidpants  to  be  effective  in  performing 
Synthesis 

•  l^th  Synthesis-novice  managers  and  engineers  as  primary  partidpants,  to  supply  essential 
domain  expertise  and  to  be  trained  in  Synthesis  practices 
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The  maturity  sdieme  also  aj^lies  to  the  individual  sections  in  Fsrt  Opp  and  Part  Lev  of  the  guidebook. 
Ikbles  and  show  the  cunent  maturity  of  eadi  section  in  Fart  Opp,  0|^rtunistic 
Synthesis,  and  in  Fart  Lev,  Leveraged  Synthesis,  respectively. 

TkUe  App-1.  Maturity  Scheme  for  Part  Opp‘,  Opportunistic  ^thesis 


Section 

Maturity 

OV.  Overview 

Exploratory 

DE.  Domain  Engineering  Overview 

Erqrloratory 

DE.1.  Domain  Management 

E]q}loratory 

DE.2.  Domain  Analysis 

Esqploratory 

DE.2.1.  Domain  Derinition  Activity 

Exploratory 

DE.2.2.  Domain  Specification  Activity 

Ejqploratory 

DE.2.2.1.  Decision  Model  Activity 

Erqrloratory 

DE.2.2.2.  Product  Requirements  Activity 

Exploratory 

DE.2.23.  Process  Requirements  Activity 

E]q>loratory 

DE.2.2.4.  Product  Design  Activity 

Exploratory 

DE.2.2.4.1  Product  Architecture  Activity 

Exploratory 

DE.2.2.4.2  Component  Design  Activity 

Exploratory 

DE.2.2.43  Component  Design  Activity 

E3q[>loratory 

DE.2.3.  Domain  Verification  Activity 

Ejqploratory 

DE.3.  Domain  Implementation  Activity 

Ejqploratory 

DE.3.1.  Product  Implementation  Activity 

Ejqploratory 

DE.3.1.1.  Component  Implementation  Activity 

Developmental 

DE.3.1.2.  Generation  Implementation  Activity 

Exploratory 

DE.3.2.  Process  Support  Development  Activity 

Exploratory 

DE.4.  Project  Support  Activity 

E3q>loratory 

DE.4.1  Domain  Validation  Activity 

Omitted 

DE.4.2  Domain  Delivery  Activity 

Omitted 

AE.  Application  Engineering  Overview 

Ejqploratory 

AT.  Advanced  Topics 

Omitted 
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Ikble  App-2.  Maturity  Sdieme  for  Part  Lev,  Leveraged  Synthesis 


Section 

Maturity 

OV.  Overview 

Exploratory 

DE.  Domain  Engineering  Overview 

Erqploratory 

DE.1.  Domain  Management 

Ejqploratory 

DE.2.  £)omain  Analysis 

Exploratory 

DE^.l.  Domain  Definition  Activity 

Developmental 

DE.2.2.  Domain  Specification  Activity 

Exploratory 

DE.2.2.1.  Decision  Model  Activity 

Developmental 

DE.2.2.2.  Product  Requirements  Activity 

Developmental 

DE.2.2.3.  Process  Requirements  Activity 

Exploratory 

DE^.2.4.  Product  Design  Activity 

E]q>loratory 

DE.2.2.4.1  Product  Architecture  Activity 

Exploratory 

DE.2.2.4.2  Component  Design  Activity 

E9q>loratory 

DE.2.2.4.3  Component  Design  Activity 

Exploratory 

DE.2.3.  Domain  Verification  Activity 

Exploratory 

DE.3.  Domain  Implementation  Activity 

Exploratory 

DE-3.1.  Product  Implementation  Activity 

Exploratory 

DE.3.1.L  Component  Implementation  Activity 

Developmental 

DE.3.1.2.  Generation  Implementation  Activity 

Exploratory 

DE.3.2.  Process  Support  Development  Activity 

Exploratory 

DE.4.  Project  Support  Activity 

Ejqploratory 

DE.4.1  Domain  Validation  Activity 

Omitted 

DE.4.2  Domain  Delivery  Activity 

Omitted 

AE.  Application  Engineering  Overview 

Exploratory 

AE.1.  through  AE.4. 

Omitted 

AT.  Advanced  Topics 

Omitted 
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USX  OF  ABBREVIATIONS  AND  ACRONYMS 


ADAKTS 

Ada-based  Design  .^ijBroadi  for  Real-Time  Systems 

AE 

Application  Engineering 

AT 

Advanced  Ibpics 

DE 

Domain  Engineering 

DOD 

Department  of  Defense 

ESP 

Evolutionary  Spiral  Process 

rv&v 

Independent  Verification  and  Validation 

Lev 

leveraged 

Opp 

opportunistic 

OV 

Overview 

RCM 

Reuse  Capability  Model 

SSS 

System/Segment  Specification 

STARS 

Software  Ibchnology  for  Adaptable  Reliable  Systems 

Syn 

Synthesis 

TLC 

Traffic  Light  Control  Software  System 

Abb-1 
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Abstract  component 

Abstraction 

Activity 

Adaptable  Component 

I 

I 

I 

Application 

Application  Engineering 

Application  Engineering  Environment 

Application  Engineering  Process  Support 
Application  Model 


A  family  of  components  diaracterized  by  a  defining 
abstraction  and  the  decisions  that  are  needed  to  dis¬ 
tinguish  among  the  members  of  the  family  (or  to 
extract  a  concrete  component), 

A  desaiption  of  a  collection  of  things  that  applies 
equally  well  to  any  one  of  them.  Also,  a  concept  that 
denotes  the  common  properties  of  a  family. 

A  step  of  a  process  for  producing  and/or  evaluating 
work  products  to  satisfy  objective(s)  supporting  that 
process.  An  activity  comprises  other  steps. 

A  Domain  Engineering  work  product  that 
implements  a  Component  Design.  See  Abstract 
component. 

The  hardware,  software,  and  manual  procedures  that 
characterize  a  system. 

An  iterative  process  for  the  design  and  development 
of  a  product  that  satisfies  specified  customer  require¬ 
ments.  Its  work  products  are  an  Application  Model 
and  an  Application  Product.  For  the  leveraged  ^- 
thesis  process,  see  Application  Modeling  (Activity), 
Application  Production  (Activity),  Delivery  and  Op¬ 
eration  Support  (Activity),  and  Project  Management 
(Activity). 

Autcanated  suppcxt  provided  fix  a  prescribed 
i^^I^cation  process.  See  I^ooess 

Ri^uirraaents  and  Process  Suppcxt  and  Infrastructure. 

A  Domain  Implementation,  from  the  perspective  of 
an  Application  Engineering  project 

A  set  of  resolved  requirements  and  engineering 
decisions,  as  specified  by  a  Decision  Model,  that 
(partially)  determine  an  instance  of  a  family  of 
systems.  See  Application  Modeling  Notation. 
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Application  Modeling  (Activity) 


Application  Modeling  Notation 


Application  Product 


Application  Production  (Activity) 


Architecture 


Assessment  (Activity) 


Business  area 


Business-area  knowledge 


Business-area  organization 


The  Application  Engineering  activity  that  produces 
a  validated  Application  Model  sufficient  to  derive  a 
production-quality  Application  Product  that  satisfies 
customer  requirements.  See  Specification  (Activity), 
Validation  (At^ty),  and  Assessment  (Activity). 

A  notation  for  expressing  an  Application  Model  such 
that  a  complete  Application  Model  is  sufficient  to 
distinguish  uniquely  any  system  of  a  domain.  See 
Process  Requirements. 

Sc^tware  artifacts,  induding  code  and  documentation, 
produced  by  the  Apj^cation  Production  activity  to  satisfy 
customer  requirements. 

The  Apf^cation  Engineering  activity  that  produces  an 
i^^cation  I^oduct,  as  specified  by  an  Ap{dication  Mod¬ 
el,  and  Deliveiy  Support.  See  Generation  (Activity)  and 
Spedal  Components  Implementation  (Activity). 

A  set  of  design  structures  that  characterize  a  system 
and  each  associated  artifact  (i.e.,  work  products). 

The  Application  Modeling  activity  that  produces 
analyses  of  the  degree  to  which  alternative 
Application  Models  satisfy  the  operational  (e.g.,  per¬ 
formance,  reliability)  and  product  quality 
requirements  of  the  customer. 

A  coherent  market  characterized  by  (potential) 
customers  possessing  similar  needs. 

Information  that  characterizes  the  market  for  a  domain 
induding: 

•  Current  and  future  customer  and  contract 
profiles 

•  Projected  growth  in  contracts  (or  sales) 

•  Value  and  marketability  of  features 

•  Market  analyses 

An  organization  whose  mission  is  the  production  and 
delivery  of  products  for  customers  in  a  specified 
business  area. 
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Business  objectives 
Candidate  Components 

Commonality 

Component 
Component  Design 

Component  Design  (Activity) 
Component  Implementation  (Activity) 

Constraint 

Customer 

Customer  requirements 

Decision 

Decision  constraint 
Decision  group 

Decision  Model 

Decision  Model  (Activity) 


The  needs  of  a  business-area  organization  that 
determine  the  scope  and  extent  of  a  domain. 

A  set  of  previously-built  components  that  have  been 
judged  as  qualified  for  potential  use  as  raw  material 
in  the  engineering  of  AdaptiiAc  Components. 

A  characteristic  of  a  domain  that  corresponds  to  a 
similarity  among  members  of  the  associated  family  of 
systems.  See  Variability. 

A  work-product  fragment  whose  production  is  a 
managed  work  assignment.  See  Abstract  component. 

The  element  of  a  Product  Design  that  defines  the 
design  of  a  component  identified  in  a  Product 
Architecture. 

The  Domain  Analysis  activity  that  creates  a 
Component  Design. 

The  Domain  Implementation  activity  that  creates 
Adaptable  Components,  as  specified  by  a  Component 
Design. 

A  limitation  on  decision(s). 

The  person(s)  or  organization(s)  that  specify  the 
requirements,  accept,  and  authorize  payment  for  a 
product. 

A  description  of  the  capabilities,  as  understood 
customers,  required  of  a  system  and  any  constraints 
on  the  engineering  of  that  system. 

A  choice  among  allowable  alternatives. 

A  set  of  constraints  on  the  resolution  of 
interdependent  decisions. 

A  logical  grouping  of  decisions  in  the  Application 
Modeling  Notation  that  allows  the  application  engi¬ 
neer  to  separate  concerns  when  describing  a  system. 

The  element  of  a  Domain  Specification  that  defines 
the  abstract  form  (concepts,  decisions,  and  structure) 
of  an  Application  Modeling  Notation. 

The  Domain  Analysis  activity  that  creates  a  Decision 
Model. 
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Decision  specification  A  specification  of  the  set  of  dedsions  that  suffice  to 

distinguish  among  members  of  a  family. 

Delivery  and  Operation  Support  (Activity)  The  Application  Engineering  activity  that  delivers  an 

Application  Product  to  customers  and  supports  its 
use. 


Delivery  Support 


Dependency  constraint 


Derived  requirements 


Design  structure 


Document 


Domain 


Domain  Analysis  (Activity) 


Domain  Assumptions 


Software  artifacts  produced  by  the  Application 
Production  activity  to  support  the  Delivery  and 
Operation  Support  activi^  for  delivery  of  an 
Application  Product  to  customers. 

A  relationship  specifying  how  decisions  made  by  an 
application  engineer  limit  subsequent  decisions. 

Requirements  that  indicate  characteristics  specific  to 
particular  systems  in  the  domain  based  on  the  deci¬ 
sions  that  an  application  engineer  expresses  in  an 
application  model. 

Aset  of  relationships  among  a  set  of  components  that 
represent  some  characteristic  of  the  aggregate.  Ex¬ 
amples  for  a  program  are  dependent^  structures  that 
define  a  program’s  static  structure  and  process 
structures  that  define  its  dynamic  behavior. 

A  documentation  component,  including  textual  and 
graphical  artifacts. 

A  product  family  and  an  associated  production 
process  supporting  a  product  line. 

The  Domain  Engineering  activity  in  which  domain 
knowledge  is  studied  and  formalized  as  a  Domain 
Definition  and  a  Domain  Specification.  The  exper¬ 
tise  in  a  business  area  is  formalized  to  create  stan¬ 
dards  for  problem  descriptions  and  corresponding 
solutions.  See  Domain  Definition  (Activity),  Domain 
Specification  (Activity),  and  Domain  Verification 
(Activity). 

The  element  of  a  Domain  Definition  that  defines  the 
guiding  assumptions  and  justifications  of  domain 
scope  and  extent. 
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Domain  Definition  An  informal’  desaipilon  of  the  scope,  extent,  and 

justification  for  a  domain.  See  Domain  Synopsis, 
Domain  Glossary,  Domain  Assumptions,  and 
Domain  Status. 

Domain  Definition  (Activity)  The  Domain  Analysis  activity  that  creates  a  Domain 

Definition. 


Domain  Delivery  (Activity) 


Domain  Engineering 


Domain  evolution 

Domain  Glossary 
Domain  Implementation 
Domain  Implementation  (Activity) 

Domain  knowledge 


The  Project  Support  activi^  that  assists  ^plication 
Engineering  projects  in  the  effective  use  of  ^^^catitMi 
Engineering  Process  Support. 

An  iterative  process  for  the  design  and  develofnnent 
of  (1)  a  product  family  and  (2)  an  Application  Engi¬ 
neering  process  for  producing  members  of  that  fami¬ 
ly.  See  Domain  Management  (Activity),  Domain 
Analysis  (Activity),  Domain  Implementation 
(Activity),  and  Project  Support  (Activity). 

Revision  of  a  Domain  Definition,  Domain 
Specification,  and  associated  Api^cation  Engineering 
Ftocess  Support  to  reflect  changes  in  domain  scope. 

The  element  of  a  Domain  Definition  that  defines  the 
terminology  of  a  domain. 

A  Product  Implementation  and  Process  Support  that 
satisfies  a  Domain  Specification. 

The  Domain  Engineering  activity  that  neates 
support  for  Application  Engineering  projects  in  the 
form  of  a  Domain  Implementation.  See  j^oduct  Im¬ 
plementation  (Activity)  and  Process  Support 
Development  (Activity). 

Knowledge  and  expertise  characteristic  to  a  domain: 

•  Relevant  scientific  theory  and  engineering 
practice 

•  Capabilities  and  uses  of  existing  systems 

•  Past  system  development  and  maintenance 
experience  and  work  products 

•  Potential  developments  in  related  or 
supporting  technology 

•  Potential  changes  in  customer  needs 
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Domain  Management  (Activity) 

Domain  objectives 
Domain  Plan 

Domain  Specification 

Domain  Specification  (Activity) 
Domain  Status 

Domain  Synopsis 
Domain  Validation  (Activity) 

Domain  Verification  (Activity) 

Entrance  criteria 


The  Domain  Engineering  activity  that  plans, 
monitors,  and  controls  the  activities  and  resources  of 
a  Domain  Engineering  organization  and  which  coor¬ 
dinates  domain  developmoit  and  evolution  with  client 
Application  Engineering  projects. 

An  element  of  the  Domain  Plan  Master  Plan  that 
defines  the  goals  of  domain  development. 

Sdiedules,  budgets,  assignments,  and  progress 
evaluations  for  the  management  of  a  Domain 
Engineering  organization. 

A  specification  of  a  standardized  Application 
Engineering  process  and  product  family  for  a  do¬ 
main.  See  Decision  Model,  Product  (Family) 
Requirements,  Process  Requirements,  and  Product 
(Family)  Design. 

The  Domain  Analysis  activity  that  creates  a  Domain 
Specification. 

The  element  of  a  Domain  Definition  that  specifies 
the  current  scope,  extent,  and  viability  of  a  domain 
relative  to  its  objectives. 

The  element  of  a  Domain  Definition  that  is  an 
informal  description  of  a  domain. 

The  Project  Support  activity  that  evaluates  the 
quality  and  effectiveness  of  Application  Engineering 
ftocess  Support  from  the  perspective  of  Application 
Engineering  project  needs. 

The  Domain  Analysis  activity  that  evaluates  a 
Domain  Implementation  to  determine  compliance 
with  the  corresponding  Domain  Definition  and 
Domain  Specification. 

Conditions  that  must  be  met  before  an  activity  can  be 
started. 


Exit  criteria 


Family 


Conditions  that  must  be  met  before  an  activity  can  be 
considered  successfully  completed. 

A  set  of  things  that  have  enough  in  common  that  it 
pa^  to  consider  their  common  characteristics  before 
noting  specific  properties  of  instances. 
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Feasibility 


Feedback 


Generation  (Activity) 


Generation  Design 


Generation  Design  (Activity) 


Generation  Implementation  (Activity) 


The  degree  to  which  an  objective  is  amenable  to 
solution  with  predictable  resources  and  risk. 

Information  communicated  by  the  consumer  of  a 
work  product  to  its  producer  regarding  issues  in  the 
correctness,  quality,  and  viability  of  the  product. 

The  Application  Production  activity  that  applies  a 
Generation  Procedure  to  an  Application  Model, 
Adaptable  Components,  and  Special  Components  to 
produce  software  work  products. 

The  element  of  a  Product  Design  that  specifies  a 
Generation  Procedure  (i.e.,  the  mapping  fi-om  a 
Decision  Model  and  Product  Architecture  to  work 
products  for  an  application). 

The  Domain  Implementation  activity  that  creates  a 
Generation  Design. 

The  Domain  Implementation  activity  that  creates  a 
Generation  Procedure. 


Generation  Procedure 


Goal 

Implicit  requirements 


Infrastructure 


Instantiation 


Iterative  process 


The  definition  of  a  procedure  for  selecting,  adapting, 
and  composing  components  to  create  a  work  product. 

A  specific,  time-related,  measurable  target. 

Requirements  that  indicate  characteristics  that  are 
common  to  ail  systems  in  a  domain.  {Comment.  These 
are  referred  to  as  implicit  because  they  are  implicit  to 
an  Application  Model  [i.e.,  there  are  no  decisions  in 
the  Decision  Model  that  affect  them]). 

Those  mechanisms  or  attributes  of  an  Application 
Engineering  Environment  that  are  not  determined 
by  the  Domain  Specification.  See  Process  Support 
Development  (Activity). 

Creating  a  thing  from  a  representation  of  an 
abstraction  denoting  a  set  of  such  things. 

A  process  in  which  completion  occurs  only  after 
repetition  of  producing  and  using  activities  results  in 
refined  work  products. 
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Legacy  Products 


Life  cycle 

Metaprogram 

Metaprogramming 

Metaprogramming  notation 

Method 

Methodology 

Model 

Module 

Objective 

Plan 

Process 

Process  engineering 


The  element  of  a  Domain  Definition  that  is  a 
collection  of  work  products  (or  portions  thereof)  that 
are  potentially  useful  raw  material  for  developing 
other  Domain  Engineering  work  products.  Legacy 
Products  are  derive  from  existing  systems  in  the 
domain. 

A  sequence  of  distinct  states  of  an  entity  beginning 
with  its  initial  conception  and  ending  when  it  is  no 
longer  available  for  use. 

A  description  of  an  abstract  component  that  is 
sufficient,  given  a  set  of  resolved  decisions,  to 
instantiate  a  corresponding  concrete  component. 

A  method  for  creating  abstract  components  and 
extracting  concrete  components  from  them.  See 
Instantiation. 

A  notation  for  defining  and  instantiating 
metaprograms. 

Guidance  and  criteria  that  prescribe  a  systematic, 
repeatable  technique  for  performing  an  activity. 

An  integrated  body  of  principles,  practices,  and 
methods  that  presaibe  the  proper  performance  of  a 
process. 

A  representation  of  a  thing  from  which  analysis 
provides  approximate  answers  to  designated 
questions  about  the  thing  itself. 

A  software  component  that  consists  of  design,  code, 
documentation,  and  test  artifacts. 

The  intended  or  desired  result  of  a  course  of  action. 

A  designation  of  tasks  and  resource  allocations  for 
accomplishing  a  specified  objective. 

A  (partially)  ordered  set  of  steps,  intended  to 
accomplish  specified  objective(s). 

The  construction  of  a  process  appropriate  to 
accomplish  the  objectives  of  an  organization  or 
project. 
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Process  Requirements 


Process  Requirements  (Activity) 


Process  Support 


The  element  of  a  Domain  Spedfication  that  defines 
an  Application  Engineering  process  and  concrete 
forms  (syntax)  of  an  assodated  Application  Modeling 
Notation. 

The  Domain  Analysis  activity  that  creates  Process 
Requirements. 

Standards  and  procedures,  in  the  form  of  documents 
and  supporting  automation,  that  institute  a  standard 
Application  Engineering  process,  as  specified  by  a 
Process  Requirements.  See  Application  Engineering 
Environment. 


Process  Support  Development  (Activity) 


Product 


Product  Architecture 


The  Domain  Implementation  activity  that  creates 
Process  Support. 

The  aggregation  of  all  work  products  resulting  from 
a  process  or  activity. 

See  Product  (Family)  Architecture. 


Product  Architecture  (Activity) 


The  Domain  Analysis  activity  that  creates  a  Product 
Architecture. 


Product  Design 
Product  Design  (Activity) 

Product  Family 

Product  (Family)  Architecture 

Product  (Family)  Design 


Product  (Family)  engineering 


See  Product  (Family)  Design. 

The  Domain  Analysis  activity  that  aeates  a  Product 
Design. 

A  family  of  products.  See  Family. 

The  element  of  a  Product  Design  that  is  a  sp>ecification 
of  the  (adap)table)  ardiitecture  of  the  products  for  a 
system  (px)ssibty  as  a  set  of  components). 

The  element  of  a  Domain  Specification  that  defines 
how  an  Application  Model  which  satisfies  the  Deci¬ 
sion  Model  determines  the  structure  and  content  of 
an  Application  Product  and  Delivery  Support.  This 
includes  the  CTiteria  by  which  components  are  se¬ 
lected  and  adapted  to  create  fragments  which  are 
then  composed  into  complete  work  products. 

The  development  and  evolution,  consistent  with  a 
Domain  Definition  and  Decision  Model,  of  Product 
Requirements,  Product  Design,  and  Product 
Implementation  corresponding  to  a  product  family. 
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Product  (Family)  Implementation 
Product  (Family)  Requirements 

Product  Implementation 
Product  Implementation  (Activity) 


Product  line 

Product  Requirements 
Product  Requirements  (Activity) 

Program 


Project 


Project  Management  (Activity) 


Project  Plan 


Project  Support  (Activity) 


The  implementation  of  a  Product  Design  as  sets  of 
Adai^^le  Components  and  Generation  Procedures. 

The  element  of  a  Domain  Specification  that  defines 
the  requirements  of  systems  in  a  domain  relative  to 
a  £)ecision  Model. 

See  Product  (Family)  Implementation. 

The  Domain  Implementation  activity  that  aeates  a 
Product  Implementation.  See  Component  Implemen¬ 
tation  (Ac^^)  and  Generation  Impdementation 
(Activity). 

A  collection  of  (existing  and  potential)  products  that 
address  a  designated  business  area. 

See  Product  (Family)  Requirements. 

The  Domain  Analysis  activity  that  creates  a  Product 
Requirements. 

(1)  An  aggregation  of  software  comix}nents  that, 
when  integrated  with  hardware,  operates  as  a  unit. 

(2)  A  directed,  funded  effort  to  acquire,  develop,  or 
maintain  a  product(s). 

An  undertaking  requiring  concerted  effort,  which  is 
focused  on  developing  and/or  maintaining  a  specific 
product.  Typically,  a  project  has  its  own  funding,  cost 
accounting,  and  delivery  schedule. 

The  Ap^dication  Ei^eerii^  activity  that  pdans, 
monitors,  and  controls  ^plication  Engineering  pro¬ 
cess  execution  and  provides  feedback  to  Domain  En¬ 
gineering  on  desired  product  family  and  Application 
Engineering  process  modifications. 

Schedules,  budgets,  assignments,  and  status 
evaluations  for  the  management  of  an  Application 
Engineering  project. 

The  Domain  Engineering  activity  that  validates 
y^plication  Engineering  Process  Support,  delivers  it 
to  application  projects,  and  supports  its  use.  See  Do¬ 
main  Validation  (Activity)  and  Domain  Delivery 
(Activity). 


k 
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Reuse  Library 
Risk 

Specialization 

Specification 

Specification  (Activity) 

Step 

Structural  constraint 

Subdomain 

Subfamily 

Synthesis 


The  pcHtion  of  an  i^jpiicatkxi  Engineenpg  Environment 
that  provides  access  to  Adaptable  Components. 

A  potential  for  incurring  undesirable  results. 

Constraining  an  abstraction  to  denote  a  subset. 

A  complete,  precise  description  of  the  verifiable 
properties  required  of  a  work  product. 

The  Application  Modeling  activity  that  analyzes 
customer  needs  to  produce  an  application  model. 
The  implication  Model  expresses  requirements  and 
engineering  decisions  that  describe  a  system 
intended  to  satisfy  those  needs. 

Either  an  activity  or  an  unelaborated  action. 

A  constraint  that  limits  the  number  of  instances  of  a 
decision  group  in  a  valid  Application  Model 

The  denotation  of  a  subfamily  of  systems  for  which  a 
corresponding  domain  denotes  the  larger  family. 

A  subset  of  the  members  of  a  family  that  have  some 
set  of  common  characteristics  not  shared  by  any 
members  of  the  family  outside  that  subset.  See 
subdomain. 

A  methodology  for  the  construction  of  software 
systems  as  instances  of  a  family  of  systems  that  have  simi  - 
lar  descriptions.  Its  primary  distinguishing  feamres  are: 

•  Formalization  of  domains  as  families  of  systems 
that  share  many  common  features,  but  which 
also  vary  in  well-defined  ways 

•  System  building  reduced  to  resolution  of 
requirements  and  engineering  decisions  that 
represent  the  variations  characteristic  of  a 
domain 

•  Reuse  of  software  artifacts  through 
mechanical  adaptation  of  components  to  sat¬ 
isfy  requirements  and  engineering  decisions 
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System 

I^sk 

Ifest  scenario 

User 

Validation 
Validation  (Activity) 

Variability 

Verification 

Viability 

Work  product 


•  Model-based  analyses  of  described  systems 
to  help  understand  the  im{dications  of 
system-building  decisions  and  evaluate  alter¬ 
natives 

A  collection  of  hardware,  software,  and  people  that 
operate  together  to  accomplish  a  mission. 

A  work  assignment  (i.e.,  subject  to  management  ac¬ 
countability)  to  accomplish  a  specified  objective. 

A  test  component,  which  includes  test  procedures 
and  test  data  artifacts. 

The  person(s)  or  organization(s)  that  will  use  the  sys¬ 
tem  for  its  intended  purpose  when  it  is  deployed  in  its 
environment. 

The  evaluation  of  work  products  tc  determine 
whether  they  satisfy  customer  needs. 

The  Application  Modeling  activity  that  produces 
analyses  of  the  d^ee  to  alternative  Application 
Models  satisfy  the  functional  requirements  of  the 
customer. 

A  characteristic  of  a  domain  that  corresponds  to 
features  that  distinguish  among  members  of  the 
associated  famify  of  ^ems.  See  Commonality. 

The  evaluation  of  a  work  product  to  determine 
whether  it  meets  its  specification. 

The  degree  to  which  benefits  of  a  feasible 
undertaking  dominate  the  costs  of  its  performance, 
taking  into  consideration  risk-induced  uncertainties. 

Any  configuration-managed  artifact. 
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